[concurrency-interest] Problem with using an unbounded map ofMutexlock objects

Dawid Kurzyniec dawidk at mathcs.emory.edu
Fri Jun 2 23:53:30 EDT 2006


Craig Mattocks wrote:
> On  Sat, 3 Jun 2006 07:02:59 +1000 Greg Luck <gluck at gregluck.com> wrote:
>
>   
>> Once a Mutex object is placed in the Map it stays there forever. It is
>> technically a slow memory leak unless the keyset is bounded so that
>> at some time it stops growing.
>>     
>
> Use a WeakHashMap?
>
>   

Nah; the keys are compared using equals() so you don't want to tie locks 
to particular object instances.

Here is a "named lock" class that may just do the trick (it is called 
"named", but in reality, the "name" of the lock can be an arbitrary 
object, with equals() comparison semantics):

http://dcl.mathcs.emory.edu/cgi-bin/viewcvs.cgi/software/util/src/edu/emory/mathcs/util/concurrent/ReentrantNamedLock.java

It does use a form of a weak map (weak _value_ map to be precise) to 
allow locks that are (1) unused and (2) unlocked to be garbage 
collected, and later re-created if needed again.

I do think, however, that lock striping may work out better b/c of 
allocation considerations.

Regards,
Dawid



More information about the Concurrency-interest mailing list