On Mon, 11 Jun 2012 13:42:37 -0400, Dmitry Olshansky
<dmitry.o...@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
