On Sunday, 7 October 2018 at 02:59:12 UTC, Manu wrote:
On Sat, Oct 6, 2018 at 7:40 PM Nicholas Wilson via
Digitalmars-d <digitalmars-d@puremagic.com> wrote:
[...]
One thing that occurred to me is that _objects_ are shared,
whereas _functions/methods_ (and their parameters) are thread
safe .
Theadsafe is kind of like a const (as to mutable/immutable) to
threading, a promise to behave correctly in the presence of
threading. thread safe references therefore must not escape.
Right, that's kinda what I want to model... but the more I
think of it, the more I think that experience can fit into
`shared`, because it's almost there, and the current
incarnation of shared is objectively useless.
Consider shared as is today;
struct Bob
{
int x;
void f() shared
{
x = 10; // <- this compiles... WAT?!
}
}
Right now, if you have a shared instance, you can read/write to
the
members... and that makes *absolutely no sense* no matter how
you look
at it.
There is no reality where you have a shared thing, and accessing
members un-controlled can be safe.
Conventional wisdom is that when you have a shared thing, and
you want
to do stuff with it, you must acquire locks (or whatever) and
case
shared away. That should apply to f() above.
struct Bob
{
int x;
void f() shared
{
auto lock = getLock();
auto unshared = shared_cast(&this);
unshared.x = 10; // <- this is now okay.
}
}
If we made a change were `shared` lost the ability to access
non-`shared` members, I don't think that would interfere with
current or proposed uses of shared in any way whatsoever... and
we would make shared useful in the process.
I think it should be more like this
shared struct Bob
{
shared int x;
void f() shared
{
Laquire:
auto owned_bob = try_aquire(&this, pthread_self());
// type will be the same as Bob* but without shared
stripped from variables
// and without any functions
if (owned_bob is null)
{
__mmPause();
goto Laquire;
}
*owned_bob.x = 10;
}
}
