This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
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

[B&S]Is this Lock/Unlock implementaion sounds ok?

 
Jahir Islam
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am working on SCJD project. Reading several posts and my spec, I finally come up with following lock/unlock mechanism. I would be glad if someone sees any problem with this approach that I am not getting.

I have a map of (recNo, List). When a client tries to lock a record, the list is generated or retrieved. Then current thread is added in the list and the list is placed in the map again.

if the current thread is NOT at the head/beginning of the list, the thread goes to wait on the list.

In unlock method, this list is retrieved again by keying the recNo. The first item is removed from the list. If the list contains more items, a notifyAll() is sent on the list. Otherways, when the list size is 0, the list is removed from the map.

The advantage is to sent notification only to the client threads which are waiting on a specific thread. Clients waiting on record 2 won't be notified when a client unlocks record 3.



[Andrew: Put source code inside UBB code tags and removed psuedo-code for unlock method (for reasons why, see the "SCJD FAQ" 'What is the policy on posting questions I saw on the exam / details of how to do the assignment?')]
[ December 21, 2004: Message edited by: Andrew Monkhouse ]
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I use a similar technique with the following differences.
- The top element on the list is treated differently, sinc there is no guarantee that the thread will remain the same for multiple calls through RMI. So I don't use the thread in that object.
- in unlock I use notify, on the nre top element of the list, which is the thread that has waited the longest. This improves fairness.
- I only synchronize on the Map and on the individual lock object that is waiting.
 
Jahir Islam
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For 1st point,
I thought for a RMI request/method one thread is spawned on the server. That thread may be blocked, waited, slept but unless the call completes that is the only thread servicing that call. I don't think RMI spawns another thread to complete parts of a request. So, if the server update(recno) impl contains



code like above, all those are executed by one thread.

After some debug and test, my impl code came close to your second and third point.
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jahir Islam:
For 1st point,
I thought for a RMI request/method one thread is spawned on the server. That thread may be blocked, waited, slept but unless the call completes that is the only thread servicing that call. I don't think RMI spawns another thread to complete parts of a request. So, if the server update(recno) impl contains



code like above, all those are executed by one thread.

After some debug and test, my impl code came close to your second and third point.


If seperate calls are made by the client over RMI for the lock, update and unlock, there is no guarantee that they will all use the same thread. Its likely, but not guaranteed.

I use the instance of the Data class that is associated with the client as the object that identifies the client. I do use the thread while its on the queue, since thats all within the lock call.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic