is(Mutex == shared) == false?

[tcak]

On Saturday, 8 February 2014 at 03:11:17 UTC, Stanislav Blinov 
wrote:
> Ditto for other core.sync primitives.
>
> This has been haunting me for a while now. Currently all those 
> guys are not qualified shared at all. What that means is that 
> we cannot use them in any shared classes:
>
> shared class C
> {
>     Mutex m;
>
>     this()
>     {
>         m = new Mutex; // error, cannot implicitly convert 
> Mutex to shared(Mutex)
>         m = new shared Mutex; // error, Mutex.this is not 
> callable using a shared object
>     }
> }
>
> Same goes for shared methods too. So the only possible ways to 
> use Mutex et al. are to either declare them __gshared, which 
> implies static, or apply casts. So we can't have per-instance 
> mutexes, condition variables, etc, unless using casts 
> everywhere.
>
> As far as I can see this state is the same between dmd, ldc and 
> gdc.
>
> So, question number 1:
>
> Is this at all intentional or just inherent and no one got 
> around to adding support for shared? I can't at all see why 
> would they be non-shared.
>
> Because if that is to change, it'd better be sooner than later, 
> right?
>
> With mutexes the roots run as deep as object_.{d,di} where the 
> Monitor interface is declared (having both lock and unlock 
> methods non-shared).
>
> I've been able to coerce my local pull of druntime to define 
> Mutex et al. as shared by default. Aside from sorcery with 
> casts inside e.g. src/gc/gc.d and combating segfaults in GC and 
> Thread initialization, it involved:
>
> - qualifying Monitor's methods as shared
> - renaming existing classes (e.g. class Mutex -> shared class 
> Mutex_)
> - providing default-shared aliases (e.g. alias Mutex = 
> shared(Mutex))
>
> The renaming and alias are needed to (a) not break existing 
> code and (b) because in my understanding they should be shared 
> anyway :)
>
> Surprisingly, this didn't take all that long, though I suspect 
> there are some underwater rocks still remaining. But at least 
> both druntime and Phobos pass their unittests.
>
> Thus, question number 2:
>
> Am I going in the right direction, or is there something 
> already planned regarding this?
>
> The complete set of changes would be rather large, as not only 
> it spans currently supported OSs, but I imagine also would 
> concern both druntime and Phobos (e.g. std.concurrency, 
> std.parallelism).
>
> I am primarily on Linux, but given time I can also edit the 
> relevant files for Windows too. However, I don't have access to 
> any other OSs, so I still won't be able to create a complete 
> pull request.
>
> Hence, question number 3:
>
> Provided you've read to this point, and question number 2 
> yields positive answer, is there anybody willing to collaborate 
> on this? E.g. complete/test the changes on Windows, OSX, etc?
>
> I understand that the community is currently battling in the 
> fields of GC vs ARC vs manual memory management, but I still 
> hope to hear your feedback :)

When I first time saw D language, I called it as my dream 
language. Well, every nice thing has its problems. I hated that 
"shared" keyword since first day. It ruins my codes whenever I 
need to write multiple thread programs.