Sharing in D

[superdan]

Sean Kelly Wrote:

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

makes sense. but i guess we agree that that is the rare case in which you're ok with a race. the usual case is you don't want a race. so i think it's fair that the rare case requires a cast. walt seems to have gotten the default right as far as i can tell.