On Saturday, 20 October 2018 at 16:41:41 UTC, Stanislav Blinov
wrote:
On Saturday, 20 October 2018 at 16:18:53 UTC, aliak wrote:
class C {
void f();
void g() shared;
}
void t1(shared C c) {
c.g; // ok
c.f; // error
}
void t2(shared C c) {
c.g; // ok
c.f; // error
}
auto c = new C();
spawn(&t1, c); // line 20
spawn(&t2, c); // line 21
c.f; // ok
c.g; // ok // line 23
Those are not "ok". They're only "ok" under Manu's proposal so
long as the author of C promises (via documentation) that
that's indeed "ok". There can be no statically-enforced
guarantees that those calls are "ok", or that issuing them in
that order is "ok". Yet Manu keeps insisting that somehow there
is.
Backing up a bit and making a few observations (after adding
imports and wrapping the bottom code in a function):
1. the code above currently does not compile, error messages are:
i. line 20 & 21: spawn fails to instantiate because c is not
shared
ii. line 23: shared method C.g is not callable using a
non-shared object
iii. the lines already marked // error
2. in order to fix 1.i, one must cast c to shared at the call
site, this is not @safe
3 fixing 1.ii requires doing `(cast(shared)c).g`, this is also
not @safe
4 fixing 1.iii fixing requires casting away shared, this is not
only not @safe, but also wrong. c is a class so one could try
locking it although I'm not sure what the implications are for
doing that when another thread owns the data, probably bad.
5 the current means of dealing with shared with lock and cast
away shared is also not @safe
6 under Manu's proposal reading and writing shared objects
results in compilation error
7 The static guarantees we have in the language are type safety
and @safe
8 under Manu's proposal to do anything one must call shared
functions on said object, this implies a "@trusted"
implementation at the bottom of the stack for ensuring thread
safety (atomics and lock + cast (assuming it is not wrong), other
sync primitives) that are not @safe, but not outright wrong
either.
The question then becomes: assuming the implementation _is_ @safe
type correct and thread safe etc., can the author of C provide
guarantees of @safe and type correctness? and can this guarantee
be free of false positives?
Currently the answer is no: the requirement to cast to and from
shared is un-@safe and that burden is on the user which means
that they must understand the inner workings of C to know it that
is the case.
Manu's proposal is slightly more interesting. shared becomes a
guarantee that accesses to that object will not race, assuming
that the @trusted implementation at the bottom of the stack are
correct. In the above if t1 and t2 took `const shared C` and `g`
was also const shared, then I think that it could.
