hi guys i am seeing some peculiar problem with the following code below?
The dought is, when a thread executes join method on another thread in a synchronized context holding a lock of some third party resource like string , then at that moment the thread does not releases the lock on the string when it executes the join stmt.
the code is
The o/p after the partial o/p the dead lock state appears. ok i am very much clear with the above concept provided the join method does not going to release the lock on the string object when any thread executes the join stmt.
iam not facing any dead lock problem in the preceding program plz reply me about the above concept? And make confirm about wheater the thread is going to release the lock when the thread is blocked using the join stmt?
Edited by Corey McGlone: Formatted Code [ January 04, 2006: Message edited by: Corey McGlone ]
I hope you've enjoyed your visits to JavaRanch. In the future, especially when posting large amounts of code, as you did here, please take the time to format it properly and use "code" tags to make it more readable. I took the time to add formatting to your code in order to make it more readble, this time. The easier you make it for everyone else to read your posts, the more likely it is that you'll get good responses.
If you need to learn more about using UBB code, take a look here.
First of all, while this doesn't necessarily answer your question, please use upper case names for your classes. It's the standard naming convention and it'll make your life easier if you get in the habit of doing it.
Now, to try to answer your question...
Umm...this doesn't even compile. The constructor needs to take a parameter and "this", all by itself, doesn't work. Perhaps you have a typo here?
However, it looks like, in your second example, that the main thread is locking on the new thread object while the new thread is locking on the String object. Because they're locking on two separate objects, you'll have no deadlock issues. If you were to make them both lock on the new thread object, like this:
I had expected this to cause deadlock, but, for some reason, it does not. I'm still trying to puzzle this one out. Did this come from a mock exam? If so, was there any explanation provided?
Originally posted by Ernest Friedman-Hill: Thread.join() calls wait() on the Thread object itself, thereby releasing the lock.
Then why does this result in deadlock?
In this case, I'm locking on the class MyThread, rather than an instance of it. This causes deadlock. If the join() method really released the lock, I would expect this code to complete normally. As it is, it hangs when the child thread reaches the synchronized block.
Joined: Dec 20, 2001
Just to add a little more to the discussion, I've also tried locking on a random instance of an object, like this:
This also causes deadlock. For some odd reason, the only time deadlock is not caused is when we try to synchronize on the instance of the thread.
The main thread has a lock on MyThread.class, and it's calling mt.join() which acquires and releases a lock on mt, but has no effect on the lock on MyThread.class. It's waiting for the child thread to finish. Meanwhile the child thread is stuck trying to acquire the lock on MyThread.class, which is unavailable.
"I'm not back." - Bill Harding, Twister
author and iconoclast
In your last two examples, the synchronization is on some object (call it O) which is not the Thread object (call it T). There are two threads, the initial one (call it M) and the new one (which we'll also call T -- shouldn't be confusing.) In both of those examples:
1) M locks O 2) M calls T.join which locks T, calls T.wait, which unlocks T 3) T tries to lock O, and can't, as M is holding the lock.
But in your non-deadlocking example, O and T are the same object, so we have
1) M locks T 2) M calls T.join which re-locks T, calls T.wait, which completely unlocks T 3) T tries to lock T, and it succeeds, since M unlocked it in (2)
Note that wait() releases all locks on an object; it's not as if there's a "lock count" which is simply decremented.
Joined: Jan 30, 2000
Or in your last code, they're fighting over the lock on lockObject instead. But the problem is the same - calling mt.join() only releases a lock on mt, not on any other objects.
Joined: Jan 30, 2000
author and iconoclast