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
