This week's book giveaway is in the Servlets forum.
We're giving away four copies of Murach's Java Servlets and JSP and have Joel Murach on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes Determine whether object's lock is held Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Murach's Java Servlets and JSP this week in the Servlets forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Determine whether object Watch "Determine whether object New topic
Author

Determine whether object's lock is held

Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Is it possible to determine what the result of
<code>synchronized(obj) { ... } </code>
will be without doing it?
I think three outcomes are possible:

  • This thread has the lock already, so execution would just continue.
  • No thread has the lock, so this thread would get it, then continue.
  • Another thread has the lock, so this thread would block.

  • If you can get this information, can you find out which thread has the lock, if it's not the current one?
    This is only for debugging.
    I sort-of expect that the answer's "no", but ...


Betty Rubble? Well, I would go with Betty... but I'd be thinking of Wilma.
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
No Not that I know of.
- Peter
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
In fact, you can find out, I just discovered from my learned boss:
The wait() and notify() methods on java.lang.Object require that you hold the lock on the object. If you do not hold the lock, these methods will throw IllegalMonitorStateException. This gives a way to determine whether you hold the lock.
The usual pattern for using wait() or notify() is to explicitly synchronise on the object before calling. But, if you call wait(a small time) or notify() on an object, without explicitly synchronising, you will find out whether you held the lock on the object. If you did, the wait() or notify() will work. If you did not, IllegalMonitorStateException gets thrown.
A little care needs to be taken, because neither wait() nor notify() are without side effects. Use of the above mechanism could cause problems if used on an object which is already involved in some type of wait()/notify() notification scheme. But, where that is not the case, it sounds to me like a very useful technique. I propose to use it for an assertion mechanism, creating a debug-build method that I can call that says "I should have the lock on such-and-such-object, please check that I do".
Peter den Haan
author
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
Originally posted by Peter Chase:
The wait() and notify() methods on java.lang.Object require that you hold the lock on the object. [...]
Often you know that simply from your position in the code. I got the impression that the immediate problem was detecting whether another object owns a lock on the object, so you can predict whether synchronized(obj) will block or not. AFAIK there is no way of doing this.
A workaround would be to code out your locking, e.g. using a read/write lock pattern. Then you can simply examine the lock flag.
- Peter
[This message has been edited by Peter den Haan (edited November 13, 2001).]
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
I hinted, but was perhaps not very clear, that this request is for debugging purposes. Of course, it should normally be possible to analyse the source code to see whether the lock will be held or not. But sometimes the source code is very complicated.
What I wanted most was to be able to add a statement of the synchronisation policy in the actual code, rather than comments, and have an assertion-style check of whether this was true. For instance, an unsynchronised method might have a synchronisation policy that it should only be called by a thread that already has a lock on the instance. I would already document this in the javadoc comments, but it is good for maintenance if I can cause the software to abort with a helpful message if a subsequent change to the software breaks my synchronisation policy.
I agree that the wait()/notify() technique does not let you determine whether an attempt to acquire the lock will block.
dan moore
Ranch Hand

Joined: Nov 04, 2001
Posts: 68
mr Chase,
your threading assertions idea sounds damn good. am interested in the practical problems though. do you intend to run these monitor exception checks in the production system or only in a test build? this would be the thorny problem i guess - in production you are incurring "unnecessary" overhead (and perhaps even breaking your policy by attempting to check compliance) and if only in a test build, you may miss a problem or even alter the build sufficiently from the production version to hide one.
can you post back your findings? i for one would really appreciate.
cheers, dan.


dan moore, infomatiq ltd.<br />email dan@infomatiq.co.uk<br /><a href="http://www.infomatiq.co.uk" target="_blank" rel="nofollow">http://www.infomatiq.co.uk</a>
Peter Chase
Ranch Hand

Joined: Oct 30, 2001
Posts: 1970
Assertions are a bit duff in Java (I believe 1.4 has assertions built in, but I don't use that yet), because there's no obvious way to exclude the code in the production/release build. Compare to C/C++ preprocessor.
The typical Java compiler is just about bright enough to exclude code that appears after an "if" that tests a constant boolean expression that is always false. Therefore, you can define a public static final boolean value called, say, CompileOptions.ASSERT, and test this before doing any debug checks. Then there is only one thing to change to switch from debug to production build.
Santosh Kumar Nayak
Ranch Hand

Joined: Aug 02, 2011
Posts: 92
Use java.lang.Thread.holdsLock() method.

Returns true or false based upon the lock status.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Determine whether object's lock is held
 
Similar Threads
Thread states, notify, notifyAll, wait
Problem in Threading
Locking
if notify() cannot take a target argument, when is it useful?
SCJD Failure