Comment Feed for Software Transactional Memory: The Current State of the Art (Going Deep on Channel 9)

Re: Re: Software Transactional Memory: The Current State of the Art

Charles — Mon, 07 Sep 2009 23:24:55 GMT

Works for me. Where are you located geographically?
C

Re: Software Transactional Memory: The Current State of the Art

Zian Choy — Mon, 07 Sep 2009 20:52:58 GMT

When I tried to click on "WMV (High)", I got sent to http://mschnlnine.vo.llnwd.net/d1/ch9/1/0/1/7/4/4/InsideSTM_2MB_ch9.wmv, which gave me a 404.

Re: Re: Re: Software Transactional Memory: The Current State of the Art

gkorland — Fri, 29 May 2009 14:55:54 GMT

We're trying to get feedback on how Java developers will want to see and use STM.

For that we established the Deuce project, providing a noninvasive Java STM.

See: http://www.deucestm.org for more details.

Re: Software Transactional Memory: The Current State of the Art

Yossi Levanoni — Wed, 31 Dec 2008 01:37:52 GMT

Charles, thanks a lot for taking the time to talk with us!

To the folks interested in this technology, you are welcome to contact us through our team blog: http://blogs.msdn.com/stmteam

Re: Re: Software Transactional Memory: The Current State of the Art

Charles — Tue, 30 Dec 2008 19:22:58 GMT

Good thinking. Indeed, the basic idea is to abstract away Threads from explicit thought (just as .NET and Java do in terms of memory allocation and lifetime management of objects via garbage collection). In fact, this is exactly what the TPL does (you program Tasks, not Threads, explicitly). This seems to be the direction the Parallel Computing Platform team is heading, but you the programmer will have to help us figure out if this is the right approach. Are threads evil? Of course not. The platform that we've built around them over the years was not designed for many-core processors so the current semantics of explicit threaded programming are, well, lacking for the general purpose programmer who simply wants to solve problems in object oriented and imperative way (sequential code composition). Rather than forcing you to learn a completely new way fo thinking, the goal is to fold concurrency and parallelism into the tools and compositional patterns already burned into your mind. Obviously, this is a very hard task, but a worthy and noble one.

See you in the middle,
C

Re: Re: Software Transactional Memory: The Current State of the Art

Charles — Tue, 30 Dec 2008 19:11:28 GMT

Indeed, software tooling innovations (languages, runtimes, libraries, design patterns and guidance) to support many-core architectures needs to catch up to hardware advances and you can bet (as mentioned in this interview) that software crafters and hardware engineers are working together very closely as we march into the age of thousands of cores per chip. It's all about meeting in the middle given the complexity of the problem on both sides. We're making real progress, but have a long way to go.

C

Re: Software Transactional Memory: The Current State of the Art

Tom Kirby-Green — Tue, 30 Dec 2008 06:24:31 GMT

Another great interview Charles. It's very encouraging to see Microsoft openly approaching the parallelism 'problem' from multiple angles. I'm really hoping that in 2009 you'll be putting up videos with the folks doing the 'side effects / mutation aware' type system evolutions that David Callahan et al referred to with a nod and wink at the PDC...

Taking a step back for a moment.

As Microsoft encourages us to elevate our thinking about concurrency and parallelism out of the quagmire of explicit threads and locks, and as more and more managed technologies enter this spaces (Tasks, PLINQ, STM etc) I wonder if it isn’t time to revisit the root namespace. Krzysztof Cwalina and Brad Abrams have long championed the notion of putting ones lower level types for ‘advanced’ or seldom encountered scenarios in a sub-namespace. Today with .NET 4 we have:

System.Threading
System.Threading.Tasks
System.Threading.Collections

And who knows, if it isn’t baked into some language maybe the future will see:

System.Threading.TransactionalMemory

However if we want to encourage folks not routinely stumble upon Thread and Mutex etc types then perhaps a better organisation would be:

System.Concurrency
System.Concurrency.Tasks
System.Concurrency.Collections
System.Concurrency.Threading
System.Concurrency.TransactionalMemory

In fact one might go so far as to effectively promote the Tasks sub-namespace types to be prime candidates for the root System.Concurrency. At least then as we move forward we can remove the bug-factory-esc lower level primitives from being the first thing developer’s encounter. It strikes me that it should be possible to enhance the Fusion binding system to allow code to safely migrate towards a reorganised namespace schema. There are echoes here of Rico Mariani’s Pit Of Success, i.e. ensuring the developers encounter best practice (types) first.

Re: Software Transactional Memory: The Current State of the Art

Vasile Paraschiv — Tue, 30 Dec 2008 05:54:57 GMT

Finally we hear a more pragmatic story on STM. No more Holy Grail! Thanks Dana and Yossi.

Too bad we did not hear much about the “The Current State of the Art” on Hardware TM. Maybe we could have heard how CISC architecture is saving our (like in “we, the software guys”) pride (read “behinds”) once again. :)