Non-atomic ops allowed on shared variables?

[Timon Gehr]

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()