On 08/12/2016 02:01 PM, H. S. Teoh via Digitalmars-d wrote:
On Fri, Aug 12, 2016 at 02:04:53PM -0400, Andrei Alexandrescu via Digitalmars-d 
wrote:
On 08/12/2016 01:21 PM, Steven Schveighoffer wrote:
On 8/12/16 1:04 PM, Jonathan M Davis via Digitalmars-d wrote:

Honestly, I don't think that shared is broken.

Yes. It is broken.

shared int x;
++x; // error, must use atomicOp.
x = x + 1; // OK(!)

How is this broken and how should it behave? -- Andrei

?!

Isn't it obvious that assigning to a shared int must require atomicOp or
a cast? `x = x + 1;` clearly has a race condition otherwise.

It is not to me, and it does not seem like a low-level race condition to me (whereas ++x is).

Currently the compiler must ensure that an atomic read and an atomic write are generated for x. Other than that, it is the responsibility of the user. The use of "shared" does not automatically relieve the user from certain responsibilities.

I agree that it would be nice to have stronger protection against higher-level bugs, but those are outside the charter of "shared". Consider:

x = *p + 1;

How would the compiler reject the right uses but not the case when p == &x?


Andrei

Reply via email to