Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Question with Habibi's Locking Example

 
Jeff Hinshaw
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Pseudocode of Habibi's lock/reserve method

void reserve/lock
Synchronized(reservedDvds)
...
reservedDvds.add
...
reservedDvds.notifyAll()

I am a little confused on this. I thought the synchronization of the collection reservedDvds automatically took care of anyone else trying to get into the collection. And, the notifyAll() was to inform anyone who did a reservedDvds.wait()

If a client did a wait, then why notify them, as this method has not released the lock?

Am I missing something, or is the notifyAll() in the lock method un-needed and should only be in the unlock method?
 
Jan Groth
Ranch Hand
Posts: 456
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi there,

if you (better: a thread) enter a synchronized block, you'll get the mutex. the jvm guarantees that you'll be the only one inside the block.

so far so good.

but: if you then call wait() on an object, the mutex is released and some other thread will be allowed to aquire it. when later this other thread calls notify/notifyall, you'll (might) get the mutex back and your business continues.

that's the whole point about it...

hope it helps,
jan
 
Jeff Hinshaw
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jan, I''m good with that. My point is that if a thread is in the synchronized code, it only "waits" if the record it wanted is locked. Therefore it would only need to be notified when the record is unlocked. Why have the notify in the lock method? Seems it should only be in the unlock method.

That make sense?
 
Jan Groth
Ranch Hand
Posts: 456
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sorry, i got you wrong.

what you write seems to make perfect sense to me, to be honest. but i definitly have to think it over, it's not so trivial as i thought when i first answered you questions.

or even better: i have the call commented out, and let my testsuite run against the code.

so far,
jan
 
Jeff Hinshaw
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have taken the notifyAll() out of my lock routine and my application seems to run well so far. Perhaps Andrew will review this thread later and provide his thoughts.

The Habibi book with the example has been a huge help to me. I had no clue how to start this project before reading the book. Now that I have finished the book I know 1000% more about locking and threading than I did before, and when I re-review his code I have a lot of questions on some of the things that were done there.
 
Andrew Monkhouse
author and jackaroo
Marshal Commander
Pie
Posts: 12014
220
C++ Firefox Browser IntelliJ IDE Java Mac Oracle
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeff,
Perhaps Andrew will review this thread later and provide his thoughts.
The problem is not reviewing this thread - it is trying to remember what was in the original book and code.

I have a vague recollection that at the time the original book was written, the Fly By Night Services assignment had certain requirements for being able to lock the entire database, and I think that the call to notify in the lock method was the starting point to waking up all threads when the entire database was locked. Unfortunately I don't remember whether I picked this up from one of the conversations with Max, or whether it was hinted at in the book.

Regardless, for the current assignments you do not need to call notify() from within the lock() method. The only time you need to call notify() or notifyAll() is from your unlock() method.

Regards, Andrew
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Andrew's right, as usual. There was a requirement @ the time that a user be able to lock the entire database( by locking record # -1). Accordingly, we wanted to let the unlock method know this, so it could choose not to allow locking of further records once a lock of the entire database had been requested.

Otherwise, someone trying to lock the entire database would never, practically speaking, be able to achieve that lock, because user who has locked active records could never be counted on to release them all at the appropriate time.

HTH,
best,
M
 
Jeff Hinshaw
Greenhorn
Posts: 21
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank's Andrew and Max.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic