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

Jonathan M Davis jmdavisProg at gmx.com
Tue Nov 20 11:07:31 PST 2012


On Sunday, November 18, 2012 14:48:02 Sean Kelly wrote:
> On Nov 18, 2012, at 12:44 PM, Jonathan M Davis <jmdavisProg at gmx.com> wrote:
> > 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).
> 
> I tried this once and it cascaded to requiring modifications of various
> definitions on core.sys.posix to add a "shared" qualifier, and since I
> wasn't ready to do that I rolled back the changes.  I guess the alternative
> would be to have a shared equivalent for every operation that basically
> just casts away shared and then calls the non-shared function, but that's
> such a terrible design I've been resisting it.

Well, this is certainly going to need to be sorted out. And given that it's 
not unreasonable that both shared and __gshared be used with the type is 
core.sync, I don't think we have much choice to duplicate most of those 
functions (probably using casting internally to avoid actually duplicating the 
implementation in most cases) unless __gshared becomes implicitly convertible 
to shared.

- Jonathan M Davis


More information about the Digitalmars-d mailing list