Forums Register Login
Monkhouse: Multiple Notification Objects example

I am trying to apply the approach that is provided in the Monkhouse book page 158 (of course with related changes to match the requirments of the B&S assignment).

in the enhanced reserveDvd(), in line number 32


this causes IllegalMonitorStateException to raise in the enhanced releaseDVD() when I signal the matching condition.

but if I move that line to the releaseDVD() i don't get the exception.
why are we unlocking inside reserveDVD(), does it harm if i move it into the releaveDVD().

another issue is the waiting time, I believe it is not allowed in our assignment to use waiting time (the spec's didn't mention anything about it) right?
[ September 02, 2007: Message edited by: Musab Al-Rawi ]
Ok I was able to figure it out and here is what I found out for those who are interested:

you have to unlock as in line 32 to avoid deadlock.
you have to lock again in release() signal then unlock.
from Denny's DVD sources freely available on apress homepage:

"lock" is limiting access to underlying Map.
If you won't unlock at the end of reserveDVD, you are limiting access to this Map until somebody else calls unlock. So it won't be possible, for example: to lock 2 records at the same time, the second call to lock would need to wait until somebody unlocks Map.
You only need to lock Map for time you are working with it and you don't want anybody else to interfere.

Also please, try to post some code snippets or at least version of sources you are reffering to. Because, information such as "line 32" is not very helpful.
Yeah sorry i missed that.
in the code posted by John:

this while why is it needed ?
as I understand only one thread can lock which is done before the loop
so there will only be one thread executing the await(), when the thread (the one actually locks the record) signals the condition.

even if there are 2 threads competing only one of them will lock the "lock" and only one will be able to call await().

what am I missing? do I have to use the while here or is it enough to put an if Statement ?
only one thread can have "lock" locked _at a time_,

thread 1 calls lock and await (giving up its lock)
thread 2 calls lock and await (giving up its lock)
thread 3 calls lock and await (giving up its lock)

so you have multiple threads waiting for the same condition. The condition in this case is: "map lock is released", but this doesn't say anything about what record was just unlocked. So if all threads will wake-up, because somebody called condition.signalAll(), all threads need to check, whether it was record they are waiting for (in while, because if it was some other record they need to wait (again)).

there are 2 things going on here:
- locking map to avoid concurrent access

- and manipulating with this map (storing logical locks - the locks from user-of-data-class point of view)

[ September 03, 2007: Message edited by: John Stone ]

but what about ReentrantReadWriteLock do they give the lock when the executing thread is blocked?

i tried to look for that info in the javadoc but i couldnt find it.
check doc to "Interface ReadWriteLock", you should find your answers there:

I assume by blocked, you mean that thread is waiting for some condition.

ReentrantReadWriteLock.ReadLock is not supporting any conditions.
ReentrantReadWriteLock.WriteLock can have conditions and these should work as in case of ReentrantLock.

But I suggest, that you read javadoc for these first (or try to re-phrase your question), and also for their interface, parent classes,.. etc, as I do not have real-life experience with these locks (and I might be wrong :-))
[ September 03, 2007: Message edited by: John Stone ]

when I said blocked I really meant when the CPU decides to move the thread to the runnable queue.

if we are using synchronized blocks (i know that locks are similar) even if the thread is moved to the runnable queue the thread won't give up the lock.

I am pretty new to the new locking ways in Java 5 so please don't mind me

This thread has been viewed 1088 times.

All times above are in ranch (not your local) time.
The current ranch time is
Oct 15, 2018 17:03:25.