• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

NX: (contractors) locking question: what should we synchronize on?

 
Rob Zidsen
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,
The instructions say "Any attempt to lock a resource that is already locked should cause the current thread to give up the CPU, <bold>consuming no CPU cycles</bold> until the desired resource becomes available."
If I use a hashmap as my lockmanager, and synchronize on it, then a call to notifyAll() would cause all sleeping threads to wake up even if if they're waiting on a different record to be unlocked. However, searching thru the archives this seems to be what everyone else does anyways, so should I be worried about this or not?
 
Mark Spritzler
ranger
Sheriff
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, how else will the clients know that the particular record that was unlocked is for them or not. That is why we call notifyAll, so that all the threads can check to see if they can get the record they want.
Don't worry you are fine here.
Mark
 
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 Rob,
I have seen at least one person here calling wait() and notify() on the record number itself. That is - the Integer equivalant of the record number that is used in the key of the Map. If I remember correctly, when a user had finished with the lock, they did not remove the entire entry from the map, they just cleared the owner value. So if a client wanted a particular lock, they checked if an entry existed in the map, and if not they created it and used it. If the entry did exist, and it had an owner associated with it, then they waited, otherwise they took ownership.
This is slightly more complex than just waiting on the entire lock collection, but it is more compliant with the instructions.
Not sure if it is overkill though - I suspect that the instructions in this case fall into the "dumb instructions" category (where the user has described what they imagine happening, not what is normally acceptable practice). Sun have acknowledged that some instructions have been created that fall into this category.
Regards, Andrew
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic