Thread-safe attribution

Stanislav Blinov stanislav.blinov at gmail.com
Sun Oct 7 12:43:28 UTC 2018


On Sunday, 7 October 2018 at 04:16:43 UTC, Manu wrote:

> We're not trying to 'stuff the nuances' into a keyword... what 
> I'm trying to achieve is a mechanism for attributing that a 
> function has
> implemented thread-safety *in some way*, and how that works is a
> detail for the function.
> What the attribute needs to do, is control the access rights to 
> the
> object appropriately, so that if you're in custody of a shared 
> object,
> you should exclusively be limited to performing guaranteed 
> thread-safe
> operations on the object, OR, you must perform synchronisation 
> and
> cast shared away (as is current use of shared).

Then I maintain that `T*` should *not* implicitly cast to 
`threadsafe T*`. It should at least be an explicit cast that you 
could grep for. Consider:

struct Bob {
     int x;
     int y;

     void readAndMutate() /* thread-local */ {
         if (x) y += 1;
     }

     void readAndMutate() threadsafe {
         auto lock = getSomeLockThatPresumablyLocksThisInstance();
         auto unshared = cast(Bob*) &this;
         unshared.readAndMutate();
     }
}

void sendToAnotherThread(threadsafe Bob* bob) {
     // pass the pointer to some thread...
}

Bob bob; // not marked `threadsafe`

void main() {

     bob.x = 1;

     sendToAnotherThread(&bob);

     bob.x = 0; // <-- that's a bug
     auto copyOfBob = bob; // <-- that's another bug

     // do the rest of main...
}

Basically, *any* non-`threadsafe` access to `bob` should ideally 
be a compiler error after the cast, but I don't think the 
language could enforce that.

These contrived examples aren't that convincing, I'm sure, but 
imagine this implicit cast hiding somewhere in a 10Kloc module.
In your own words: "I don't think that you should...": then we 
would need at least some way to succinctly find such problems.

There's actually an even more subtle bug in `main` above. Since 
the `bob` instance is not marked in any way, the compiler 
(optimizer) would have no idea that e.g. moving reads and writes 
to bob's fields across that implicit cast must be illegal. I 
guess a cast should then act as a compiler barrier.

> You need to read the rest of the thread... I've moved on from 
> this initial post.

Yeah, sorry about that. The thread also got split :\



More information about the Digitalmars-d mailing list