Should core.sync.mutex.Mutex, core.sync.condition.Condition, etc. have all their methods be shared?

[Dmitry Olshansky]

11/18/2012 10:36 PM, Alex Rønne Petersen пишет:
[snip]
>> Everything else stays. It's the globally shared data and it has tight
>> restrictions on what you can do with it. As such it is (just like
>> immutable) is safely passable between threads.
>
> There have been proposals to a completely different meaning of shared
> that has nothing to do with memory models or atomic ops. There is no FUD
> here. Shoehorning shared in its current state into core.sync is just
> plain unreasonable given that nothing has been set in stone about the
> meaning of shared at all yet.
>

I'd argue that shared on these objects has nothing to do with memory 
models and atomics. It's about global visibility and access to API that 
is interlocked on OS-level anyway. It works with any sane definition 
that doesn't forget to add that 'shared' implies global visibility.

>>
>>> All I can say is, let's wait with this until we know what shared is
>>> going to actually do. We don't want to do something we'll regret later.
>>
>> Obviously we know what shared is. It's just certain details need
>> straightening up. And certainly druntime/std.concurrency should add more
>> support for it where meaningful.
>
> We don't know at all what shared is. Have you been following the other
> thread? People have wildly different ideas of what it should do.
>

I admit dismissing a lot of proposals from that thread on sight. The 
ones being about shared somehow 'just working' and getting you safe way 
to sharing and the one about auto-magically attaching mutexes to shared 
stuff.

Given now that the thread is mostly spent. If there many good different 
concepts I'd appreciate if you list these here.

> I don't see why we should be in a hurry to add shared to core.sync in
> particular.

> Practically all of the runtime and standard library can't
> work properly with shared anyway, so it's not going to change a whole
> lot.

In part because even things that are supposed to always be shared in 
fact are not working as shared. And that's because nobody have found the 
time to go on and do this work.

Add the fact that say class instances have monitor field when everything 
is TLS by default for me is indication of one thing only - during a move 
to TLS by default and shared a lot of things were not updated 
accordingly because of the lack of time and other issues.

> I think it's much more sensible to wait until shared's semantics
> are set in stone and *then* start adapting the runtime and standard
> library.
>
> I can't stop anyone from just doing this, of course, but it seems like a
> premature change to me.
>
What change in semantics of shared could stop mutex object from making 
sense only as a shared object? I mean the kind of change that can 
realistically can happen not some vague idea.

-- 
Dmitry Olshansky