• Andrei Alexandrescu (14/14) Nov 30 2009 I'm thinking of adding a final method to Object:
• Sean Kelly (8/25) Nov 30 2009 I'm not sure it helps, but this could be tested now using Mutex. Doing ...
• Jason House (3/23) Dec 01 2009 There are recursive acquire variants of thin locks. IIRC, the initial CA...

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

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.

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