concurrency

Bedros Hanounik 2bedros at NOSPAMgmail.com
Sun Feb 3 22:10:09 PST 2008


I think the best way to tackle concurrency is to have two types of functions

blocking functions (like in the old sequential code execution)

and non-blocking functions (the new parallel code execution)

for non-blocking functions, the function returns additional type which is true when function execution is completed

for example


a = foo();

// para1_foo and para2_foo are completely independent and executed in parallel

b = para1_foo();
c = para2_foo();

// wait here for both functions to finish
// another syntax could be used also

if (b.done and c.done)
     continue:


I'm not sure about supporting non-pure functions (or allowing accessing global vars); it's just too ugly for no good reason.



Sean Kelly Wrote:

> 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