Non-atomic ops allowed on shared variables?

[Timon Gehr]

On 12/03/2011 11:30 PM, Jonathan M Davis wrote:
> 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

There is nothing wrong with shared. The type system is just not 
expressive enough to allow some perfectly fine code without casting to 
and away from shared now and then. Making it expressive enough would 
make the language more complex. And that system still would quite 
certainly be more conservative than necessary.