# Tuesday, 29 October 2002
« James works (sort of) | Main | Dependencies »
java.lang.Thread issues

I worked on java.lang.Thread and ran into two issues. In .NET it is not possible to:

  • obtain the interrupted status of a thread (other than the current thread)
  • test for Monitor ownership

I worked around the interrupted status issue by always returning false when you query a thread other than the current thread :-( and to test for Monitor ownership I do a Monitor.Wait on the object, with a timeout of 0. That works, but it isn't safe, because Wait temporarily releases the Monitor (if we do own it), and that could cause a deadlock :-(

Tuesday, 29 October 2002 17:03:28 (W. Europe Standard Time, UTC+01:00)  #    Comments [3] Tracked by:
"lose weight very fast without diet pills" (lose weight very fast without diet p... [Trackback]
"Online poker sites" (Online poker sites) [Trackback]

Thursday, 31 October 2002 04:14:20 (W. Europe Standard Time, UTC+01:00)

I think I can solve the interrupt status thing in the GNU Classpath Thread implementation
by keeping this flag inside the main Thread class.
Could you review the proposal that I made at http://mail.gnu.org/pipermail/classpath/2002-October/002655.html
It could take a few weeks before I start working on it though.


The proposal gives the same "solution" to the holdsLock() not implemented problem.
But I hadn't realized that wait() could of course give up the lock. Bad...
A better "solution" could then be calling notify() on the object.
Then you don't loose the lock and correctly written code (that does a wait in a while(!condition) loop)
keeps working correctly.

Friday, 01 November 2002 12:00:50 (W. Europe Standard Time, UTC+01:00)

Your proposal is actually where I stole the idea from (although I didn't realize it).


I don't like using notify(), because I'm sure there is a lot of code that depends on notify not being spurious (I've written at least a few classes that depend on that). I just re-read the documentation and I don't believe it is allowed to notify an object, if you don't mean it.


Regarding the interrupted flag, I did consider that, but for my specific VM that still leaves the problem that a thread can be interrupted from .NET code, and that wouldn't set the flag.

Friday, 01 November 2002 11:27:28 (W. Europe Standard Time, UTC+01:00)

Could you use the "real solution" for the current thread (where it works now), the "interrupted flag" trick for other threads for situations where it applies, and fall back to false (as you do now) only if *both* those approaches fail?
Stuart
Name
E-mail
Home page

I apologize for the lameness of this, but the comment spam was driving me nuts. In order to be able to post a comment, you need to answer a simple question. Hopefully this question is easy enough not to annoy serious commenters, but hard enough to keep the spammers away.

Anti-Spam Question: What method on java.lang.System returns an object's original hashcode (i.e. the one that would be returned by java.lang.Object.hashCode() if it wasn't overridden)? (case is significant)

Answer:  
Comment (HTML not allowed)  

Live Comment Preview