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
