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
