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

[Andrei Alexandrescu]

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?

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


Andrei