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
> > > superdan wrote:
> > > > Walter Bright Wrote:
> > > >>> So "shared" will tell the compiler to automatically fence, etc?
> > > >> Yes.
> > > >
> > > > yech. so i write this:
> > > >
> > > > ++a; ++b; ++c;
> > > >
> > > > and very different code comes down the pike depending on a or b or c
> > > > being shared. not easy to clarify the code is correct. this ain't
> > > > cool.
> > > If conventional code were generated for i++, and i was accessed from
> > > multiple threads, the code is *broken*.
> >
> > Not necessarily.  If i is a 32-bit number and only one thread is
> > doing the writing then the code could be perfectly safe.
> >
> i don't think so. reading must be still fenced if at least one thread writes to
it. walt is correct.

Yeah, but the "i++" is safe, which is all I was implying.  Technically
the read doesn't even need to be fenced so long as the reader doesn't
care if they then operate on a stale value, but it's rare for that to be the case.
 However, I think I do use this approach in core.Thread
in Tango for a flag somewhere.  Kinda risky, but I don't want to pay
for the ~70 cycles a lock would require and I really don't care if
the value is a bit stale.  But in these instances, I think it's
totally okay to require the user to take extra steps to indicate that
this is his intention.  core.Atomic, for example, has msync.raw to
indicate that no synchronization should occur, but a bidirectional
fence is the default if no sync flag is passed.


Sean