valid uses of shared

[Steven Schveighoffer]

On Mon, 11 Jun 2012 13:42:37 -0400, Dmitry Olshansky  
<dmitry.olsh at gmail.com> wrote:

>> a) lock the block that contains it
>> b) use some library feature that uses casting-away of shared to
>> accomplish the correct thing. For example, atomicOp.
>>
> It may be a good idea. Though I half-expect reads and writes to be  
> atomic. Yet things like this are funky trap:
> shread int x; //global
> ...
> x = x + func();
> //Booom! read-modify-write and not atomic, should have used x+= func()

We cannot prevent data races such as these (though we may be able to  
disable specific cases like this), since you can always split out this  
expression into multiple valid ones.  Also, you can hide details in  
functions:

x = func(x);

But we can say that you cannot *read or write* a shared variable  
non-atomically.  That is a goal I think is achievable by the type system  
and the language.  That arguably has no real-world value, ever, whereas  
the above may be valid in some cases (maybe you know more semantically  
about the application than the compiler can glean).

>
> While I've missed a good portion of this thread I think we should  
> explore this direction. Shared has to be connected with  
> locks/synchronized.

Yes, I agree.  If shared and synchronized are not connected somehow, the  
point of both seems rather lost.

As this was mostly a brainstorming post, I'll restate what I think as a  
reply to the original post, since my views have definitely changed.

-Steve