concurrency

Sean Kelly sean at f4.ca
Sun Feb 3 20:01:08 PST 2008


Robert Fraser wrote:
> 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.)

STM actually offers worse performance than lock-based programming, but
in exchange gains a guarantee that the app won't deadlock (though I
believe it could theoretically livelock, at least with some STM
strategies).  Also it's simply easier for most people to think in terms
of transactions.

For the average application, I think it's a preferable option to
lock-based programming.  However, I think even STM will only get us so
far, and eventually we're going to need to move to more naturally
parallelizable methods of programming.  The 'pure' functions and such in
D are an attempt to get some of this without losing the imperative
syntax that is so popular today.

> 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.

If we're talking about D, then I agree.

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

Me either, but from what I've heard, this is not typical.



More information about the Digitalmars-d mailing list