www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - useSameLockAs

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
I'm thinking of adding a final method to Object:

final void useSameLockAs(Object another);

What it does is to make "this" give up on its own lock object and use 
the same lock as "another". Probably this may restrict implementations 
to some degree (e.g. I'm not sure how that would work with thin locks).

The advantage is that you can easily create lists, trees etc. that 
ostensibly use one lock per object, when they really all use only one 
lock, as the doctor prescribed.

The catch is that this only works well if the cost of recursive acquire 
(acquiring an already-acquired lock) is low enough. I haven't kept up 
with the relative costs; last time I looked recursive locks were still 
quite expensive, but I think the tradeoffs have changed a fair amount. 
Does anyone have some hard data?


Andrei
Nov 30 2009
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
Andrei Alexandrescu Wrote:

 I'm thinking of adding a final method to Object:
 
 final void useSameLockAs(Object another);
 
 What it does is to make "this" give up on its own lock object and use 
 the same lock as "another". Probably this may restrict implementations 
 to some degree (e.g. I'm not sure how that would work with thin locks).
 
 The advantage is that you can easily create lists, trees etc. that 
 ostensibly use one lock per object, when they really all use only one 
 lock, as the doctor prescribed.
 
 The catch is that this only works well if the cost of recursive acquire 
 (acquiring an already-acquired lock) is low enough. I haven't kept up 
 with the relative costs; last time I looked recursive locks were still 
 quite expensive, but I think the tradeoffs have changed a fair amount. 
 Does anyone have some hard data?

I'm not sure it helps, but this could be tested now using Mutex. Doing this is a bit wonky because there isn't a function for it, but: Object a, b, c; auto m = new Mutex( a ); b.__monitor = a.__monitor; c.__monitor = a.__monitor; The mutex is garbage collected so cleanup isn't an issue, though this means "synchronized" couldn't be used in the objects' dtors (this just occurred to me today). I'll try to find some time to run timings of recursive vis. non-recursive mutexes. I don't think anyone would notice today anyway though, since D uses recursive mutexes by default. It would just impose a restriction on what we /could/ do.
Nov 30 2009
prev sibling parent Jason House <jason.james.house gmail.com> writes:
Andrei Alexandrescu Wrote:

 I'm thinking of adding a final method to Object:
 
 final void useSameLockAs(Object another);
 
 What it does is to make "this" give up on its own lock object and use 
 the same lock as "another". Probably this may restrict implementations 
 to some degree (e.g. I'm not sure how that would work with thin locks).

There are recursive acquire variants of thin locks. IIRC, the initial CAS tries to write its thread id. If the CAS fails, it next reads the value to see if it matches the thread id. I've been wondering if template magic can be used to better emulate Bartosz's ownership scheme. I haven't posted about it since I haven't worked out the details. I think it'd require a class to have a template parameter representing the owner of the class, and each member would be similarly templated. The tricky part is distinguishing between locked and unlocked variants of the same class. I'm thinking the unlocked variant would be a facade that can acquire the lock and then do an operation, or return a scope instance of the locked object when the calling code acquires the lock.
 
 The advantage is that you can easily create lists, trees etc. that 
 ostensibly use one lock per object, when they really all use only one 
 lock, as the doctor prescribed.
 
 The catch is that this only works well if the cost of recursive acquire 
 (acquiring an already-acquired lock) is low enough. I haven't kept up 
 with the relative costs; last time I looked recursive locks were still 
 quite expensive, but I think the tradeoffs have changed a fair amount. 
 Does anyone have some hard data?
 
 
 Andrei

Dec 01 2009