File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Determine whether object's lock is held

 
Peter Chase
Ranch Hand
Posts: 1970
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ...
 
Peter den Haan
author
Ranch Hand
Posts: 3252
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No Not that I know of.
- Peter
 
Peter Chase
Ranch Hand
Posts: 1970
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 3252
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1970
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 68
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Peter Chase
Ranch Hand
Posts: 1970
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 141
Eclipse IDE IntelliJ IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Use java.lang.Thread.holdsLock() method.

Returns true or false based upon the lock status.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic