Sharing in D

[superdan]

Sean Kelly Wrote:

> == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> > Sean Kelly wrote:
> > > In my opinion, the easiest way to describe the hardware side of things is
> > > simply to say that the CPU does the exact same thing as the optimizer in
> > > the compiler, only it does this dynamically as the code is executing.  The
> > > rest just involves ideas for how to constrain CPU and compiler optimizations
> > > so the app behaves as expected when concurrency is involved.  In your defense,
> > > "volatile" is a perfectly suitable minimum for D, so you did get the gist of
> > > the issue, even at the outset.  The catch is that, while "volatile" controls
> > > the compiler, you still need to control the CPU, so inline ASM is required
> > > as well.  Fortunately, D has that :-)  So please give yourself a bit more
> > > credit here.  D1 works perfectly well for concurrent programming.  It just
> > > support this is a sufficiently non-obvious way that only people who
> > > understand the issues involved are likely to realize it.  But as most of
> > > this stuff should really be in a library anyway, I don't see a problem
> > > with things as they are.
> > Java has synchronization and volatile, and it isn't good enough.
> 
> But volatile in Java is completely different.  And Java doesn't support inline
> ASM.  That said, Java post JSR-133 (ie. Java today) is actually fine.  The C++
> 0x people simply didn't copy Java because the Java memory model is too
> strict to appease the performance-crazed folks in the group :-)

i'm afraid c++ and c++0x and java are "actually fine" to write multiprocessing code if the coder is fucking superman on steroids after an overdose of ritalin. as far as threads are concerned these are as good as brainfuck to code in. you also say d1 is perfectly fine to do multiprocessing in. i think that's at best naive. sorry sean.