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

[deadalnix]

Le 29/05/2012 01:35, Alex Rønne Petersen a écrit :
> 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.
>
> But I take it you agree that synchronized (this) and similar
> "uncontrollable" synchronization blocks should be avoided?
>

I would say that breaking things here, with the right deprecation 
process, is the way to go.

shared isn't working properly ATM, so anyway, things will have to change 
in regard of shared memory support in the language.