File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Threads again... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Threads again..." Watch "Threads again..." New topic
Author

Threads again...

Annie Naqvi
Ranch Hand

Joined: May 04, 2001
Posts: 39
Jq+
Question ID :988384705515
[code]
public class Test extends Thread
{
static Object obj1 = new Object();
static Object obj2 = new Object();
public void m1()
{
synchronized(obj1)
{
System.out.print("1 ");
synchronized(obj2)
{
System.out.println("2");
}
}
}
public void m2()
{
synchronized(obj2)
{
System.out.print("2 ");
synchronized(obj1)
{
System.out.println("1");
}
}
}

public void run()
{
m1();
m2();
}
public static void main(String[] args)
{
new Test().start();
new Test().start();
}
}
Select the right ans:
1. it may cause deadlock
2. Nothing can be said for sure.
3.There is no potential for deadlock.
4.The prog. will always print 1 2,2 1,1 2,and 2 1
Ans.1 & 2
Hi Paul Anil,
I think the ans for this code is not right as i have compiled the prog.and always got 1 2,2 1,1 2,2 1.
I think it must 3&4.
Anyone who can tell me if i am right?
Regards,
Annie.
Muhammad Farooq
Ranch Hand

Joined: May 08, 2001
Posts: 356
You are right annie, 3 & 4 are correct, thats what I get when I compile and run.
--Farooq


Muhammad Farooq<br />Sun Certified Programmer for Java 2 Platform<br />Oracle8i Certified Professional Database Administrator
Annie Naqvi
Ranch Hand

Joined: May 04, 2001
Posts: 39
Thus it mean that JQ+ has got wrong ans too.
Paul must see this..

[This message has been edited by Annie Naqvi (edited August 16, 2001).]
Nguyen Trung
Greenhorn

Joined: Aug 16, 2001
Posts: 6
Hi Annie and Muhammad,
In my opinion 1. answer is true. Dead lock can occur when
the 1st thread finishes the m1() and tries to lock obj2 as it goes on with m2(), at the sometime the 2nd thread starts and tries to lock obj1 as it starts executing m1() method. So both of them manage to acquire their locks.
Then 1st thread try to lock obj1, 2st thread try to lock obj2 and they are waiting for each other.
Please correct if i'm wrong.
Annie Naqvi
Ranch Hand

Joined: May 04, 2001
Posts: 39
Thanx Nguyen you have given a good scenario to explain it,Paul has also mentioned something like this but I don't know why I was not gtting the point..(may be my mind was overflowing with the concepts of thread ..)
Paul you may take rest now as you are right...
Annie.
Muhammad Farooq
Ranch Hand

Joined: May 08, 2001
Posts: 356
Here everything looks to be in a sequence, the first thread calls start() --- > calls run()--- > calls m1() and then m2(), the same process is repeated for second thread. I dont see any deadlock neither does the execution of these code show any signs of deadlock.
Please comment, AAA.
--Farooq
Fernando Padilla
Greenhorn

Joined: Aug 20, 2001
Posts: 1
Here is my take on it.
First, programs designed to run in parallel ( ie. Threads ) can be very undeterministic. This arises from the possible scheduling issues... ( knowing this should flag #2 as being a correct statement, unless you are definite otherwise ).
While knowing that it can be very undeterministic, let's try to break this down. Let's try to map this programming problem into real space.
Let's imagine. Suppose we have a pencil and a pen ( these will act as our lock objects obj1 & obj2 ). And we have a two step task.

partOne {
pickup pencil;
draw box;
pickup pen;
draw star in box;
putdown pen;
putdown pencil;
}
partTwo {
pickup pen;
draw circle;
pickup pencil;
draw triangle in circle;
putdown pencil;
putdown pen;
}

Then get two people, and try to have them carry out this task at the same time. At least you should be able to see that while one has the pen, in hand the other one can't. Now if both persons start at the same time they both try to get the pencil, but only one gets it, and the other one waits for it. So at some point in the future the first person finishes with the whole first part before the second even has a chance to start.
Then they MIGHT both start partTwo and partOne at the same time.
One gets the pencil the other the pen, but then each one is waiting for the other one to finish so that they can continue with their individual task. The one with then pencil waits for the pen, while the one with the pen waits for the pencil.
The issue here is the MIGHT. It is actually the responsibility of a Thread Scheduler to let the Second thread or person know when the first lock or pencil is actually available. So the second person said, "I'm waiting for the pencil." It is up to the scheduler to say, "stop waiting, here it is." This scheduler has to deal with many many threads throughout the system, so it is undeterministic, how quickly or slowly it will do it's job because it could conceivably depend on every little thing occuring on your machine ( OS, other programs, clock, sound card, video card, anything ).
When you compiled and ran the example, we saw no deadlock. This could only have occured if the first person finished partTwo before the scheduler started person two up and the second person started to carry out partOne. With modern day CPUs I guess this is what we were all seeing.
Make a simple modification and you will see it. Add Thread.sleep( 500 ) statements in the code after each synchronized () line. This will slow down the processing allowing the scheduler time to get the second thread started on m1(), thus allowing the second thread time to get a lock on obj1 while the first thread has a lock on obj2.
Again, you might say.. but you are purposefully breaking the program, that shouldn't proove anything. The thing is that the processing power of any one thread is arbitrarily determined by the scheduler ( or at least thats how you should think of it ). So it could slow one thread down, for no apparent reason. Remember, the scheduler has to manage many other threads from many other processes.
For example, this 1/2 second delay that I arbitrarily inserted in the code, could be easily manifested by possibly running the same program on a machine that is overloaded - ie. windows like machine with MSWord and Excel chugging on really huge documents. You're going to see the scheduler making some threads run really slowly. Possibly making our threads slowdown enough to behave like demonstrated.
This is why #1 is correct as opposed to #3. But as we saw in the discussion above, we can't predict the scheduler, so #2 is correct as well.
hopefully this will help.. someone
Metal Zhang
Ranch Hand

Joined: Aug 05, 2001
Posts: 52
Hello!
I think the answer which the book gives you is correct.
Have you noticed that the answer "1" and answer "2" never say the deadlock will always appear.In fact,no one can make sure if the deadlock will happen or not.But there is really a potential deadlock in the code.It may be random if the deadlock will happen.
------------------
Java lover from hell!


Java lover from hell!
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Threads again...