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