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

[Dmitry Olshansky]

To separate an important notion I'm trying to express.

I assume that:

class X{
...
	shared foo(...);
	void bar(...);
...
}

shared X sharedStuff;
X localStuff;

Implies under any viable definition of shared that (including the 
current one and any pending clarifications):

a) foo can be called with sharedStuff in multiple threads at the same 
time. Thus it has to be thread safe (irregardless of possible 
@system/@trusted hackery inside).

b) localStuff on the other hand can called with  bar (and any non-shared 
methods) only in a single thread at any time. If localStuff is defined 
at global scope each thread has its own copy thus this requirement is 
fulfilled kind of automatically.

The major benefits of shared lie in cleaning up the opposite - unshared 
stuff. Having shared enables us to archieve great things we haven't 
looked at yet (maybe because of bugs/issues in the other departments). 
I'll name a few.

We can have lock-less and _safe_ file I/O  by default unlike e.g. C and 
pretty much everybody else. I should have said safe & _faster_  by 
default. This is why I believe D should stop relying on C's I/O as 
anything but fallback. We even had a partially complete design for new 
std.io that does it.

Same goes for memory allocations - lock-less thread-local allocators are 
possible _safely_ and by default (though it would have to go to the OS 
from time to time and likely to lock something here). It's not explored 
and remains as unused potential.

-- 
Dmitry Olshansky