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

[deadalnix]

Le 30/05/2012 22:31, Steven Schveighoffer a écrit :
> On Wed, 30 May 2012 15:48:47 -0400, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>
>> To clarify:
>>
>> On 5/30/12 12:25 PM, Alex Rønne Petersen wrote:
>>> The mutex may not be
>>> directly exposed in the sense that you can obtain a reference (though in
>>> reality in all compiler implementations, you can), but it is exposed in
>>> the sense that you can lock and unlock it, which is a mutation of state
>>> and program flow.
>>
>> 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.
>
> 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.
>
> 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!".
>
> My contention is that if the default is you do *not* expose the mutex to
> external callers, there *cannot* be a deadlock.
>
> 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.
>
> -Steve

This cannot remove all deadlocks, but yes, it goes in the right direction.