Thread-safe attribution
Manu
turkeyman at gmail.com
Sun Oct 7 01:59:21 UTC 2018
So I'm working on a SMT infrastructure, and expression of
thread-safety is a core design mechanic... but I'm really struggling
to express it in terms of the type system.
I figure I'll throw some design challenges out here and see if anyone
can offer some good ideas.
The thing I'm trying to model is an attribute along the lines of
`shared`, but actually useful ;)
I'll use the attribute `threadsafe` in place of `shared`, and see
where that goes.
Consider:
struct Bob
{
int x;
threadsafe Atomic!int y;
void m1();
void m2() threadsafe;;
void overloaded();
void overloaded() threadsafe;
}
void func(Bob x, threadsafe Bob y)
{
x.x = 10; // fine
x.y = 10; // fine
x.m1(); // fine
x.m2(); // fine
x.overloaded(); // fine, use the un-threadsafe overload
y.x = 10; // ERROR, a threadsafe reference can NOT modify an
un-threadsafe member
y.y = 10; // fine
x.m1(); // ERROR, method not threadsafe
x.m2(); // fine
x.overloaded(); // fine, use the threadsafe overload
threadsafe Bob* p = &x; // can take threadsafe reference to
thread-local object
}
This is loosely what `shared` models, but there's a few differences:
1. thread-local can NOT promote to shared
2. shared `this` applies to members
For `shared` to be useful, it should be that a shared reference to
something inhibits access to it's thread-local stuff. And in that
world, then I believe that thread-local promotion to shared would work
like const does.
I guess I'm wondering; should `shared` be transitive? Perhaps that's
what's wrong with it...?
More information about the Digitalmars-d
mailing list