Thread-safe attribution

[Stanislav Blinov]

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?