Sharing in D

[Sean Kelly]

== Quote from superdan (super at dan.org)'s article
> Sean Kelly Wrote:
> > == Quote from Walter Bright (newshound1 at digitalmars.com)'s article
> > > Sean Kelly wrote:
> > > >> 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 :-)
> > >  From talking to people who do large scale multithreaded Java programs,
> > > it is not fine. The problem is that there is no way to look at a
> > > non-trivial piece of code that you didn't write, and determine if it has
> > > dependencies on sequential consistency or not.
> > > I'm not arguing that a thread expert cannot make a thread correct
> > > program in Java and C++. They can. The problem is the inability to
> > > verify such correctness, no help is available from the language, and the
> > > dearth of such experts.
> >
> > That's the problem with providing such fundamental support for lock-free
> > programming: people will try it, and they'll invariably get it wrong.  This
> > is actually the reason why I like the minimalist approach of D 1.0 with
> > 'volatile'.  Support for lock-free is sufficiently subtle that it's unlikely
> > to be used outside of library code.
> fraid you might have a slightly specialized definition of what lock-free code
is. i think you say that cas-based shit is lock free. but here, this is lock free:
> data = 5.4;
> dataThere = true;
> people use lock-free *everywhere*. just they don't call it that way. they just
synchronize through atomic assignments.

Yeah that's true.  What drives me crazy about this is that there's no way to
tell from inspection whether the programmer knew what they were doing.  You end
up having to check all the uses of 'data' to find out.  I guess this is Walter's
point about static checking.  If 'data' were shared then I could trust that it
would "just work."  In Tango, you'd do:

    atomicStore( data, 5.4 );

And that would label the assignment as "safe" to a reader, but other uses of
'data' could still be broken.

> i'm not sure at this point how d's shared will improve the above. if i
understand that shit correctly you define data and dataThere as shared. then you
know assignments occur in the proper sequence (because of the inserted fences and
shit). if they weren't shared they could be assigned in the wrong order but nobody
could tell. it's like the shit in the forest that don't stink because nobody's
smellin'. and if they weren't shared they wouldn't be shareable to start with. so
the whole shit works. is that true walt?

This sounds right.  My only concern for the injected fences is that it won't always
result in optimal code for what the user is doing.  But it will be safe, which I
guess is pretty important (by "optimal" I mean that you don't always need fences
for an operation depending on the hardware and on whether you care about code
movement across the operation).


Sean