aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Removing entry from HashMap when storing ReentrantLocks safely Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Removing entry from HashMap when storing ReentrantLocks safely" Watch "Removing entry from HashMap when storing ReentrantLocks safely" New topic
Author

Removing entry from HashMap when storing ReentrantLocks safely

Ehsan Rahman
Ranch Hand

Joined: Feb 16, 2009
Posts: 59

Hi Everyone,

After coding up the locking section of the Data.class using synchronized methods and wait()/notify() calls for handling threads which are tying to lock on records already locked by other threads; I realized that technically the notify() call can wake up a thread wanting to lock on a different record. Better explained here

Oricio Ocle wrote:Ok think about that:


If the specified record is already locked by a different
client, the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked.



.... But it's record has not been unlocked ...

Regards


So, I've now used ReentrantLocks similar to what Simon suggests here:

Simon Cockayne wrote:Hi Liviu,

Have a HashMap recordLocks: mapping key is wrapped a recNo. Mapping value is a RecordLock object.

A RecordLock class extends ReentrantLock and has a reference to the recordLock owner and a reference to a unique condition.

Ergo, any thread that wants to wait on the recordlock (so it can update the owner informaiton) can call theCondition.await().

And any thread that has finished with a recordLock (having unlocked it say) can call theCondition.signal().



This works fine but I'm struggling with removing the entries from the Map<RecNo, RecordLock>, where RecordLock just contains a ReentrantLock with a concurrent.locks.Condition to group the specific threads that wish to be woken up as the unlock of a specific record occurs to meat the criteria "the current thread gives up the CPU and consumes no CPU cycles until the record is unlocked."

I've been looking at WeakHashMaps and the ReentrantLock methods such as getHoldCount() or hasQueuedThreads() but it just seems difficult to safely remove the entries (and ensure no othre thread is waiting/using the ReentrantLock object). Of course, I could just leave them in the Map<,> and explain it doesn't take up much memory at all. Or I wonder if someone is going to answer that the original wait()/notify() is good enough and that if one just writes about it in their choices.txt that's it's easier for a junior programmer perhaps Oracle might let you off or just deduct a few points at worst ...

Many Thanks


SCJP 1.5, SCJD 1.6
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5536
    
  13

You could use notifyAll instead of notify, that will wake up all waiting threads. The threads which are waiting for another record will go back in the waiting state, the other ones (waiting for the record which was just unlocked) will start to compete for the lock on this record.


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Ehsan Rahman
Ranch Hand

Joined: Feb 16, 2009
Posts: 59

Hi Roel, thank you. I'm just being pedantic, that's all.

I think even using notifyAll(), a thread waiting on another record, as it wakes up and before it goes back to a waiting state will consume some CPU cycle as Oricio wrote.

e.g.


Outputs:


Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5536
    
  13

Ehsan Rahman wrote:I think even using notifyAll(), a thread waiting on another record, as it wakes up and before it goes back to a waiting state will consume some CPU cycle as Oricio wrote.

That's true, but I also used a wait/notifyAll approach and passed, so I guess this CPU cycle (to check if the record it was waiting for came available) are not violating the instructions.
Ehsan Rahman
Ranch Hand

Joined: Feb 16, 2009
Posts: 59

Thanks Roel. Very interesting.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Removing entry from HashMap when storing ReentrantLocks safely