• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Monkhouse: Multiple Notification Objects example

 
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

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

dvdLock.unlock();


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 ]
 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yeah sorry i missed that.
 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
lock.lock();
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 ?
 
John Stone
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks,

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.
 
John Stone
Ranch Hand
Posts: 332
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Musab Al-Rawi
Ranch Hand
Posts: 231
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
well,

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
 
If you try to please everybody, your progress is limited by the noisiest fool. And this tiny ad:
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com
reply
    Bookmark Topic Watch Topic
  • New Topic