useSameLockAs

[Jason House]

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