useSameLockAs

[Sean Kelly]

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.