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

[Alex Rønne Petersen]

On 30-05-2012 11:15, deadalnix wrote:
> Le 30/05/2012 01:25, Alex Rønne Petersen a écrit :
>> On 30-05-2012 01:22, Andrei Alexandrescu wrote:
>>> On 5/29/12 4:17 PM, Alex Rønne Petersen wrote:
>>>> On 30-05-2012 01:10, Andrei Alexandrescu wrote:
>>>>> On 5/29/12 4:06 PM, Alex Rønne Petersen wrote:
>>>>>> Synchronized blocks are good because they
>>>>>> operate on an implicit, hidden, global mutex. You can't screw up with
>>>>>> that.
>>>>>
>>>>> I think there's quite some disconnect here. If there's any
>>>>> anti-pattern
>>>>> in this discussion, it's operating on an implicit, hidden, global
>>>>> mutex.
>>>>> Walter agreed to eliminate that from D, but never got around to it.
>>>>>
>>>>> Andrei
>>>>
>>>> I'd love to hear why you think this design is problematic as opposed to
>>>> one that lets users accidentally expose synchronization issues to
>>>> consumers of their API surface, which is what many people end up doing
>>>> since synchronized (this) or even synchronized (this.classinfo) are
>>>> allowed at all.
>>>>
>>>> (I've seen countless cases of those two horrible abuses of synchronized
>>>> especially from people asking questions on e.g. IRC.)
>>>
>>> I think the most egregious example is synchronization by global lock
>>> done in Python and other languages. It has very nice semantics (stop the
>>> world, do something, resume the world), but scales poorly enough to be
>>> universally considered a failure. Quite honest I'm shocked that you're
>>> advocating it.
>>>
>>> Andrei
>>>
>>>
>>
>> I'm not advocating it. I don't use it myself. I'm just saying that I
>> find it to be less of an issue than synchronizing on arbitrary objects,
>> because the latter is error-prone.
>>
>> And yes, Python is a textbook example of synchronization gone completely
>> wrong. But that doesn't mean that you don't sometimes have to
>> synchronize on some global resource, and in those cases, it can be
>> useful syntactic sugar (but certainly not essential).
>>
>
> I have to agree with Andrei here. The global mutex isn't the solution
> either. The mutex should be explicit, and under control (not this).

I've been arguing for being explicit all along. :)

What I've been saying in this particular part of the thread is just that 
synchronized blocks that don't operate on a specific monitor object are 
less error-prone. Nothing else.

-- 
Alex Rønne Petersen
alex at lycus.org
http://lycus.org