Assignment of shared values
Peter Alexander via Digitalmars-d
digitalmars-d at puremagic.com
Thu Aug 7 11:22:30 PDT 2014
On Thursday, 7 August 2014 at 16:44:37 UTC, Andrei Alexandrescu
wrote:
> Yah. The basic intent behind "shared" is to disallow unwitting
> racy code, and allow users to define robust shared abstractions.
>
> Consider this code at top level:
>
> struct S {
> private long a, b, c;
> ...
> }
> shared S g_theS;
>
> All threads will "see" the same g_theS. The intent of "shared"
> is to disallow racy/wrong use of g_theS across threads.
> However, assigning g_theS is by default allowed and does
> something definitely racy.
>
> So I think we should do the following:
>
> * if S.sizeof <= size_t.sizeof, generate atomic assignment
> automatically for shared values.
>
> * if S.sizeof == 2 * size_t.sizeof, generate special 128-bit
> atomic assignment for shared values on 64-bit systems, and
> 64-bit atomic assignment on 32-bit systems.
>
> * In all other cases, reject code during compilation and
> require an opAssign for shared values.
>
> This will break code. It may even break correct code (benign
> races or code that uses external locking). On the other hand,
> it seems like the right thing to do by the intended semantics
> of "shared".
Even with that change, you'll still be able to do:
S otherS = ...;
g_theS.a = otherS.a;
g_theS.b = otherS.b;
g_theS.c = otherS.c;
Right? This violates the same invariants as:
g_theS = otherS;
Can you explain the practical benefits of enforcing atomicity of
shared objects only at the individual statement level? I must be
missing something.
More information about the Digitalmars-d
mailing list