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. */
}
----
