• 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

URLyBird Locking Inquiry

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello there.

I have read many of the forum messages concerning the locking for the URLyBird project. Some of the proposed solutions strike me as industrial strength and would seem to demonstrate a strong command of the subject of locking.

Reading the assignment, I came to the personal conclusion that a simple, correct solution would probably be better for me than a feature rich solution that I might code incorrectly.

So, from the assignment:



My proposed solution is similar to the following code. Superflous items such as exception handling, access modifiers, casting out of a collection, etc. have been stripped out to simplify the discussion. Further, assume the neccessary functionality is added to make LockManager a singleton.

[edit] do not post complete code snippets

As LockManager is a singleton, there is a gareentee that only one exists so there should be no trouble locks being held by some other LockManager.

Assume no locks exist and a locking attempt is made.

A lock requestor, identified by a Cookie, requests a lock on object. An attempt is made to grab the monitor associated with the object to be locked. Assume it is successful. A check is made to see if there is an existing lock owner and there is not. An entry is added to the locks collection indicating a lock exists on object by lock owner. The break exits the while loop, the sychronized block ends, causing the thread to release the monitor associated with the object to be locked. It continues its thread of execution, owning a lock on object.

Assume while the above process is occurring, but prior to the above thread releasing the monitor, another thread requests a lock on the same object with a different lock owner.

The attempt to grab the monitor fails as it is owned by the first thread. It waits until the first thread releases the monitor on the object to be locked. Once it acquires the monitor, it determines that there is already a lock associated with the desired object and that it is not the owner of that lock. It goes into the wait set for the object to be locked and relinquishes the monitor on the object to be locked. At this point, it should consume no CPU time, a requirement of the assignment. Further, at this point, no one owns the monitor on the object to be locked.

Assume an additional 0 to n threads, all with different lock requestors, also attempt to acquire a lock on the same object as above.

The all follow the above flow and end up in the wait set for that object, consuming no CPU time. Again, at this point, no one owns the monitor of the object to be locked.

Assume some time later a request comes to unlock the object, potentially from an all together new thread, but with a lock releasor value matching the current lock holder.

The thread attempts to grab the monitor associated with the object to be unlocked. It is either successful, or will be successful shortly as the locking algorithm releases the monitor on lock success and lock wait. It determines that it owns the lock, removes the lock from the lock collection and notifies one arbitrary waiting thread that was waiting on the monitor. It then releases the monitor and exits.

Back in the lock routine, one arbitrary waiting thread wakes up and successfully acquires the monitor. It loops in the while loop and determines that there are no locks on the object. It adds a lock to the locks collection, releases the monitor and exits, now owning the lock on the object.

Things This Does Not Handle

1) Multiple lock attempts on the same object by the lock requestor that currently owns the lock all succeed, but do not stack. So the first unlock attempt essentially removes all the locks. I am not concerned about this because that functionality is not required for the assignment.

2) The solution is based on the monitor of the object to be locked, so no other part of the application can rely on the monitor of those objects. I am not concerned about this because that functionality is not required for the assignment. Further, if I change my mind and become concerned about it, it should be a simple matter to create a delegate object in the LockManager and lock on its monitor instead. That delegate object would likely be the very object used in the locks collection to identify the lock owner.

Am I missing anything?

[ May 04, 2006: Message edited by: Andrew Roy ]
[ May 04, 2006: Message edited by: Andrew Roy ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic