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

[Dmitry Olshansky]

On 31.05.2012 22:33, Andrei Alexandrescu wrote:
> On 5/31/12 7:49 AM, Dmitry Olshansky wrote:
>> 1. synchronized class means: always allocate hidden monitor mutex, lock
>> it on every public method of this class.
>
> Great.
>
>> 2. synchronized(x,y,z) is lowered to (I use Steven's idea):
>> auto sorted = total_order(x,y,z);//conceptual, sorted is tuple of x,y,z
>> sorted
>> FOR EACH item IN sorted tuple add code in [[ ... ]]
>> [[// conceptual
>> item.__lock();
>> scope(exit) item.__unlock();
>> ]]
>> In other words it works for every object that defines lock/unlock.
>> Multiple object version works only if there is opCmp defined. (by
>> address whatever, any total ordering should work)
>
> Great. What are regular calls to synchronized class methods lowered into?

Posted in another reply, basically same lock(); scope(exit)unlock() of 
hidden monitor.
>
>> Per definition above synchronized classes AS IS can't be *synchronized*
>> on. Instead their public methods are implicitly synchronized.
>>
>> The end result is:
>>
>> User can synchronize on various synchronization entities and even plug
>> in custom synchronization primitives (say OS Y provides have this fancy
>> lock type Z). It's explicit in as sense that object supports it via
>> __lock__/unlock. Obviously one still can use __lock/__unlock explicitly
>> just don't forget to wear big HERE BE DRAGONS banner.
>>
>> Synchronized class encapsulate mutex completely - nobody aside from
>> designer of the class may (a)use it.
>>
>> Does it makes sense?
>
> It does make sense, but I think we need a Lock struct type that makes
> sure code cannot screw up the number of lock and unlock calls. We
> shouldn't just expose bare lock() and unlock().
>

Dunno. In fact __lock/__unlock could be artificially hidden from user 
but not compiler with his magic rewrites.
But I believe there is value in having access to lock/unlock for those 
select cases where it's beneficial.


-- 
Dmitry Olshansky