Memory Models: A Case for Rethinking Parallel Languages and Hardware

I read a paper on the subject of transactional memory years ago that was presented at OOPSLA in 2007 (I think). It was pitching the idea that there is an analogy between transactional memory and garbage collection. It made the topic more understandable for me and might be helpful:<p><a href="http://www.cs.washington.edu/homes/djg/papers/analogy_oopsla07.pdf" rel="nofollow">http://www.cs.washington.edu/homes/djg/papers/analogy_oopsla...</a><p>I think this is an interesting explanation. The software product my company makes depends on a multi-threaded program which to date has had only one bug related to the fact it is a multi-threaded application. That bug was very serious mind you but it's the only one we've found (so far).

Every paper written by Hans Boehm is worth reading: <a href="http://www.hpl.hp.com/personal/Hans_Boehm/pubs.html" rel="nofollow">http://www.hpl.hp.com/personal/Hans_Boehm/pubs.html</a><p>(If the paper you want to read is behind a pay-wall, google its title and you will likely find a freely available copy.)

<i>if the programmer writes disciplined (data-race-free) programs</i><p>The idea seems to have merit, but such a phrase (staring with "if the programmer") also means that it will be diluted once it hits the programming mainstream. (Just a fact of life.)

Fine grained concurrency will motivate the next big paradigm shift. I haven't seen anything better than actors or STM yet though.