Sharing in D

[Sean Kelly]

== 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 :-)

> > 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.

So "shared" will tell the compiler to automatically fence, etc?  Will any actual
enforcement be done?  And if so, will this be at compile time, run time, or
both?

> > 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.

I think that cast is already used far too much as a standard programming
mechanism in D 2.0.  And I'll admit that I don't entirely understand why
you don't like const_cast but assertUnique or whatever does exactly that
behind the scenes.  Should we consider cast to be an evil red flag-throwing
feature or not?

> > 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.

That's certainly possible.  But I do think it would require the solution to
be pervasive rather than just in D if Intel were to pay attention.  That
said, I'd most prefer release consistency for a hardware memory model
(somewhat like the Itanium) combined with hardware transactional
memory.  I'm actually a bit disappointed that the Itanium wasn't
successful.  The basic design was solid.


Sean