concurrency

[Robert Fraser]

Denton Cockburn wrote:
> Ok, Walter's said previously (I think) that he's going to wait to see what
> C++ does in regards to multicore concurrency.
> 
> Ignoring this for now, for fun, what ideas do you guys have regarding
> multicore concurrency?

There were two solutions for concurrent programming proposed at the D 
conference. Walter talked about automatic parallelization made available 
functional programming styles, which Craig & Daniel are discussing. The 
other solution presented, which I have seen comparatively little 
discussion in the NG about, was software transactional memory.

I don't think that STM necessarily leads to simpler or more readable 
code than lock-based concurrency, however I think STM has two distinct 
advantages over these traditional methods:
1. possibly better performance
2. better reliability (i.e. no need to worry about deadlocks, etc.)

I think an ideal solution is two combine the two techniques. If 
functional-style programming is emphasized, and STM is used where 
state-based programming makes more sense, it frees the programmer to 
write code without worrying about the complexities of synchronization.

That said, I never found traditional concurrency that hard, especially 
within frameworks like SEDA, etc.