Non-atomic ops allowed on shared variables?

[Jonathan M Davis]

On Saturday, December 03, 2011 22:56:41 Timon Gehr wrote:
> On 12/03/2011 09:49 PM, Jonathan M Davis wrote:
> > On Saturday, December 03, 2011 21:41:45 Andrej Mitrovic wrote:
> >> On 12/3/11, Jonathan M Davis<jmdavisProg at gmx.com>  wrote:
> >>> That page says that reads and writes are guaranteed to be atomic for
> >>> shared. It does _not_ say that something like ++threadsCount is
> >>> guaranteed to be atomic.
> >> 
> >> Woops, sorry it was a typo. I meant page 411, not 413. It says it's an
> >> error there. Btw, I never said ++ was atomic, I've asked whether
> >> something has changed. IOW I thought perhaps this used to be an error
> >> but maybe it was changed to make increment/decrement to be atomic on
> >> shared variables. That's not the case of course..
> > 
> > Ah, okay. I had completely forgotten about that. That seems _very_
> > restrictive to me, and for it to work correctly, I would expect the
> > compiler to have to be smart enough to realize when a synchronized 
> > block is in use or a mutex is in use, and I don't see how it can be
> > that smart across function calls (since if it isn't that smart, it
> > forces you to use atomicOp even when it's completely unnecessary), so I
> > don't see how that could possibly work without unnecessarily requiring
> > you to use atomicOp all over the place.
> > 
> > I have no idea what the plan on this is at this point, and I'm very
> > surprised that such a requirement was ever suggested. It's the kind of
> > question that you may have to bring up in the main newsgroup if you
> > want a good answer for it though, since the number of people who pay
> > attention to d-learn is much lower, and I don't know if any of the key
> > devs who _would_ know pay attention here.
> > 
> > - Jonathan M Davis
> 
> cast()

Sure, you could cast away shared, but there's something seriously wrong with 
shared if you have to constantly cast it away in order to use a shared object.

- Jonathan M Davis