Sharing in D

[Walter Bright]

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.

> Finding a way for the average user to do safe concurrent programming is an
> entirely different issue in my opinion, and has only really been "solved," in
> my opinion, in the functional programming realm.  And that's by eliminating
> data sharing--the bane of imperative languages everywhere.

D will eliminate implicit data sharing. To share data, you'll have to 
mark it as shared, and with the marking will come extra help in fences 
and synchronization. I've looked at the two classic multithreaded 
problems - double checked locking, and sequential consistency between 
threads. This model prevents both of them from happening.


> I disagree.  D is a systems language first and foremost.  Much of the
> rest can be done in library code.  That isn't to say that I wouldn't
> like improved multiprogramming support in the language for the things
> that are awkward to do in library code (a thread-local storage class,
> for example), but trying to prevent the user from shooting himself in
> the foot is unnecessary.
> Particularly if doing so incurs a runtime
> cost that is not avoidable.

It is avoidable if you're willing to insert a cast. Putting in the cast 
says "I know how to handle the wild west, let me do it." The cast has 
zero runtime cost.


> There was some talk in the C++0x memory model discussion that Intel
> was actually planning on providing equivalent or stronger guarantees
> for future processors rather than weaker ones.  I'll admit to having
> been very surprised at the time, but apparently they feel that they
> can do so and still provide the performance people expect.  I guess
> the resounding failure of the Itanic forced them to rethink what was
> required for a successful new processor design.  If I remember
> correctly, it was Paul McKenney that brought this up if you feel like
> searching the archives.

Intel may be reacting to the disastrous problems conventional languages 
have with this. If it is solved (and I think we have a credible 
solution), Intel may change their direction.