Should core.sync.mutex.Mutex, core.sync.condition.Condition, etc. have all their methods be shared?
Jonathan M Davis
jmdavisProg at gmx.com
Sun Nov 18 12:44:20 PST 2012
On Sunday, November 18, 2012 23:28:03 Dmitry Olshansky wrote:
> 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.
I thought that it was blindingly clear from TDPL and even the online spec what
shared is for. It marks variables as being shared across threads rather than
thread local. I don't see how that could possibly be changing. __gshared isn't
even _mentioned_ in TDPL, and I think that it gets used as much as it does is
entirely because of some of the current issues with shared's implementation in
the compiler and the lack of support in druntime and Phobos.
There are definitely questions as to what exactly should happen when a variable
is marked as shared, but they have to do with what protections you get and
what conversions are possible. They still don't fundamentally change the fact
that the point of shared is to share an instance across threads rather than
have it be thread local like everything is by default.
So, I concur in that I don't see how the semantics of shared could possibly
not be appropriate for mutexes. I started this thread primarily because I was
shocked that Mutex, Condition, etc. weren't marked with shared already, and I
didn't see how they could even be used without it (and apparently, the answer
to that is that almost everyone cops out and uses __gshared).
- Jonathan M Davis
More information about the Digitalmars-d
mailing list