shared - i need it to be useful

[ag0aep6g]

On 10/15/2018 08:46 PM, Manu wrote:
> 1. traditional; assert that the object become thread-local by
> acquiring a lock, cast shared away
> 2. object may have shared methods; such methods CAN be called on
> shared instances. such methods may internally implement
> synchronisation to perform their function. perhaps methods of a
> lock-free queue structure for instance, or operator overloads on
> `Atomic!int`, etc.
[...]
> Assuming the rules above: "can't read or write to members", and the
> understanding that `shared` methods are expected to have threadsafe
> implementations (because that's the whole point), what are the risks
> from allowing T* -> shared(T)* conversion?

As far as I understand, the rule "can't read or write to members" is for 
the compiler, right? I can still read and write members, but I have to 
cast `shared` away and ensure thread-safety myself?

If that's so, then my example from the last thread might still apply:

----
struct Bob
{
   int* p;
   void doThing() shared
   {
     p = &s; /* Might need a cast or two here, and a lock or an atomic 
store or whatever. */
   }
}
shared int s;
----

When the needed casts etc. are added, is `doThing` allowed? If not, I 
think you have to specify more precisely what a method can and can't do.

If `doThing` is ok, you can't allow T* -> shared(T)*. You'd be allowing 
aliasing an unqualified int* with a shared(int*):

----
void main()
{
   Bob* b = new Bob;
   shared(Bob)* sb = b; /* You'd allow this line. */
   sb.doThing();
   /* Now the unqualified int* b.p points to the shared int s. */
}
----