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

[deadalnix]

Le 29/05/2012 01:38, Alex Rønne Petersen a écrit :
> On 29-05-2012 01:35, Alex Rønne Petersen wrote:
>> On 29-05-2012 01:24, Jonathan M Davis wrote:
>>> On Tuesday, May 29, 2012 01:11:49 Alex Rønne Petersen wrote:
>>>> I have no idea how synchronized classes work; they are not a documented
>>>> feature of the language. We have synchronized functions which
>>>> synchronize on the this reference. Perhaps synchronized classes just
>>>> make all functions in a class do this.
>>>
>>> Per TDPL, having individually synchronized functions is illegal.
>>> Either all
>>> of the functions in a class are synchronized or none of them are.
>>> Putting
>>> synchronized on a function should actually be illegal. It belongs
>>> only on
>>> classes or in synchronized blocks, never on functions.
>>>
>>> Now, unfortuntately, I don't believe that the compiler enforces any of
>>> that
>>> right now, so you end up synchronizing indivdual functions rather than
>>> whole
>>> classes, but the synchronized functions themselves should function the
>>> same.
>>>
>>>> Either way, this is a fundamental language design fallacy. This is
>>>> anti-pattern number one when it comes to locking:
>>>>
>>>> * http://stackoverflow.com/a/251668/438034
>>>> * http://msdn.microsoft.com/en-us/library/ms173179.aspx (The lock and
>>>> SyncLock Keywords section)
>>>
>>> Well, then you should probably be arguing about the design of
>>> synchronized
>>> classes/functions rather than synchronized(this). However, given the
>>> design of
>>> synchronized classes, synchronized(this) would probably never be
>>> appropriate.
>>> If you're using a synchronized class, then you don't need it. And if
>>> you're
>>> not using a synchronized class, then you shouldn't be synchronizing your
>>> class. I would definitely think that synchronized blocks should
>>> synchronize on
>>> something else, since they're trying to lock a much smaller area than an
>>> entire class.
>>>
>>> - Jonathan M Davis
>>
>> I don't think arguing about them makes sense at this point. Way too much
>> code would break if we changed the semantics. I'd consider it a mistake
>> and a lesson learned, rather.
>
> I should probably add that Java learned it long ago, and yet we adopted
> it anyway... blergh.
>

That is what I was about to say. No point of doing D if it is to repeat 
previously done errors.