zlacker

I think that's all you need for version 1.0. All the bleeding-edge concurrency abstractions like software transactional memory are only that: abstractions. Henning is right that they're going to become increasingly important in the future, but as long as you have threads and atomicity as building blocks, you should be able to do all the rest in the macro system.

Just make sure that some concurrency package eventually becomes a de facto standard. Getting C libraries that use different threading implementations to interoperate is a nightmare, and I'd hate to see Arc go the same route.

>>dfrank+(OP)
In general, combining multiple packages that each attempt to perform concurrent operations is error prone, especially if they use locking. The STM papers make an interesting argument for why using transactions rather than locks as the typical concurrency primitive leads to concurrent programs that can be more easily composed.

>>neilc+B1
That's why it's really nice to see that Arc has threads and an atomic-execution mechanism. GHC-style Software Transactional Memory would be a natural fit, and it seems to scale very well.

Locks seem to be on their way out.

>>neilc+B1
On that note, you might take a glance at the lightweight concurrency paper; it proposes a new concurrency runtime for GHC, basically moving most of the implementation into Haskell, with just a thin layer of primitives in the RTS. Interestingly, those primitives don't include locks, but instead a very minimal transactional memory.

http://research.microsoft.com/~simonpj/papers/lw-conc/index....

(The paper is also notable for giving a complete operational semantics of the system it discusses.)

(But this stuff isn't in GHC mainline, and won't be, for now, because it needs serious performance work first.)