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