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

deadalnix deadalnix at gmail.com
Wed May 30 02:15:01 PDT 2012


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).


More information about the Digitalmars-d mailing list