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

[deadalnix]

Le 31/05/2012 13:13, Andrei Alexandrescu a écrit :
> On 5/31/12 3:27 AM, Regan Heath wrote:
>> I think
>> the mutex is "available for locking and unlocking" <- need a word for
>> that, which is not "exposed". How about accessible, available, usable,
>> or just plain lockable .. So, the problem here is that the mutex is
>> lockable by external code via synchronized() and this means a certain
>> type of deadlock is possible.
>
> But this is a protection/visibility issue, which is orthogonal on the
> locking capability. It's as if you say "int is not good because anyone
> can overflow it." Okay! Make it private inside a CheckedInt class.
>
>> Moving on..
>>
>> I think the change mentioned in TDPL to restrict synchronized to
>> synchronized classes is a step in the right direction WRT wasted monitor
>> space and people freely locking anything. But, it is exactly the case
>> which results in more possible deadlocks (the cause of this thread) AND
>> I think it's actually far more likely people will want to use a
>> synchronized statement on a class which is not itself synchronized, like
>> for example an existing container class.
>>
>> Given that, restricting synchronized statements to synchronized classes
>> seems entirely wrong to me.
>
> So where's the mutex that would be used to synchronize objects that are
> not synchronizable?
>
>> In fact, I would say you almost want to stop
>> people using synchronized statements on synchronized classes because:
>> 1. If a synchronized class is written correctly it should not be
>> necessary in the general case(*)
>> 2. It raises the chances of deadlocks (the cause of this thread).
>> 3. It means that classes in general will be simpler to write (no need to
>> worry about synchronization) and also more lightweight for use in
>> non-threaded/non-shared cases. (because we'd provide a template wrapper
>> to make them synchronizable)
>
> There are cases in which you want to do multiple operations under a
> single critical section, even though the API is otherwise well-designed.
> That may be for correctness, efficiency, or both. I don't see why we'd
> want to disallow that, it's a good idiom.
>

Because it is now unclear who is controlling the lock.

The solution consisting in passing a delegate as parameter or as 
template is superior, because it is now clear who is in charge of the 
synchronization, reducing greatly chances of deadlock.