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