On Sunday, 7 October 2018 at 02:01:17 UTC, Manu wrote:
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;
Storing shared and local data together? Ew, cache poison. Be that
as it may, given that definition:
1. Can you copy Bob or assign to it? If so, how?
2. Can Bob have a destructor? Who calls it if it can?
[snip]
x.m1(); // ERROR, method not threadsafe
x.m2(); // fine
x.overloaded(); // fine, use the threadsafe overload
I guess these three should be y., not x.?
threadsafe Bob* p = &x; // can take threadsafe reference to
thread-local object
I'm not sure what's that supposed to accomplish. It looks like a
silent cast, which is already a red flag. What is the purpose of
this? Give that pointer to another thread while the original
continues to treat 'x' as thread-local? I.e. if the arguments
were indeed `ref`, the caller would be blissfully unaware of such
a "transaction" taking place.
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...?
IHMO, `shared` should be transitive, but... most uses of `shared`
should just boil down to primitive types (i.e. atomics) and
pointers to shared primitives and structs. With dereferencing
latter requiring to be synchronized, casting away `shared` in the
process, and I don't see how the language as it is can help with
that, as accessing different kinds of data requires different
code. We can't just stuff all the nuances of thread-safety and
multi-core communication into one keyword, whatever that keyword
may be.
What could be the static (compile-time) guarantees of
`threadsafe` methods?
