synchronized (this[.classinfo]) in druntime and phobos

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed May 30 14:45:32 PDT 2012


On 5/30/12 1:31 PM, Steven Schveighoffer wrote:
> On Wed, 30 May 2012 15:48:47 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> synchronized (object) {
>> writeln("about to unlock the object");
>> XXX
>> writeln("unlocked the object");
>> }
>>
>> Replace "XXX" with a construct that unlocks the object.
>
> This is not what we are talking about.

Oh yes it is. "Expose the mutex" means "make the two mutex primitive 
operations lock() and unlock() freely usable against the mutex object".

> I guess the easiest way to say it is, the API used to "lock and then
> subsequently unlock" the mutex. That is, even this:
>
> Object o = new Object;
>
> synchronized(o)
> {
> }
>
> is exposing the mutex in such a way that you can interfere with the
> semantic meaning of the mutex, and cause preventable deadlocks.
>
> It would be preferrable for:
>
> synchronized(o)
> {
> }
>
> to be an error, unless typeof(o) allows it explicitly.

Yah, it should be only allowed for synchronized classes.

> I gave you a case where you can have a deadlock, even with simple fully
> synchronized classes. You might say, "yeah, but all mutexes can have
> deadlocks!".

Not only I might say that, I'm actually gonna say it. Yeah, but all 
mutexes can have deadlocks!

> My contention is that if the default is you do *not* expose the mutex to
> external callers, there *cannot* be a deadlock.

That's shuffling the fundamental issue from client code to library code. 
This can be done in either approach (synchronized vs. raw mutex), except 
it's clunkier with raw mutex.

> Here is the example again:
>
> synchronized class A
> {
> private int _foo;
> @property int foo() { return _foo;}
> }
>
> synchronized class B
> {
> private A _a;
> @property A a() { return _a;}
> void fun() {}
> }
>
> void thread(B b)
> {
> synchronized(b.a)
> {
> b.fun();
> }
> }
>
> If synchronized(b.a) is valid, deadlock can occur. If it's invalid,
> deadlock *cannot* occur.

I don't get what this is supposed to prove.


Andrei


More information about the Digitalmars-d mailing list