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 :\

Reply via email to