Removing entry from HashMap when storing ReentrantLocks safely

[Ehsan Rahman]

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.

Supose that:
Client A locks         record 1
Client B locks         record 2
Client C tries to lock record 1 -> Giving up CPU
Client B unlocks       record 2 -> NotifyAll waiting threads
Client C tries to lock record 1 -> Consuming CPU cycles

.... 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

[Roel De Nijs]

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.

[Ehsan Rahman]

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.

public class WakeMeUpBeforeYouGogo {

    public static void main(String[] args) {
        new WakeMeUpBeforeYouGogo().go();
    }

    synchronized private void methodThatWaits() {
        while (true) {
            try {
                System.out.println(Thread.currentThread().getName() + " "
                        + "about to wait");
                wait();
                System.out.println(Thread.currentThread().getName() + " "
                        + "wakes up");
            } catch (InterruptedException ex) {
            }
        }
    }

    synchronized private void methodThatNotifies() {
        if (true) {
            System.out.println(Thread.currentThread().getName() + " "
                    + "about to notify in 3 seconds ...");
                try {
                    Thread.sleep(3000);
                    notifyAll();
                } catch (InterruptedException ex) {
            }
        }
    }

    private void go() {

        new Thread(new Runnable() {

            public void run() {
                methodThatWaits();
            }
        }).start();

        new Thread(new Runnable() {

            public void run() {
                methodThatNotifies();
            }
        }).start();
    }
}

Outputs:

Thread-0 about to wait
Thread-1 about to notify in 3 seconds ...
Thread-0 wakes up
Thread-0 about to wait

[Roel De Nijs]

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]

Thanks Roel. Very interesting.