aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Thread Behaviour? Help!!! Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Thread Behaviour? Help!!!" Watch "Thread Behaviour? Help!!!" New topic
Author

Thread Behaviour? Help!!!

Stephen Batsas
Ranch Hand

Joined: Jan 22, 2002
Posts: 117
Hi everyone,
Only three days left. I urgently need you all to check my analysis of thread behaviour as
many mock exams are inconsistent. Listed below are 5 scenarios. The code has been compiled and run for each program. Correct me where I am incorrect.
// MyRunnable.java
// Testing the behaviour of concurrent threads at the mercy of the O/S.
// "Platform used in this test is the one that needs continuous rebooting."
public class MyRunnable implements Runnable{
public void run(){

System.out.println(Thread.currentThread().getName());

}
public static void main(String[] args){

MyRunnable mr = new MyRunnable();
Thread T1 = new Thread(mr,"Thread One");
Thread T2 = new Thread(mr,"Thread Two");
Thread T3 = new Thread(mr,"Thread Three");
T1.start();
T2.start();
T3.start();
System.out.println("Thread Main");
}
}
/*Scenario above has no synchronization or yielding. All the threads are competing for CPU time with the main thread. Therefore the output cannot be determined. However when I run this program the "Main Thread" is always printed first. Is it safe to say that the main thread will execute first as the order of the rest cannot be determined. Or is this unpredictable with pre-emptive OS */

// MyRunnable1.java
public class MyRunnable1 implements Runnable{
public synchronized void run(){

System.out.println(Thread.currentThread().getName());

}
public static void main(String[] args){

MyRunnable1 mr1 = new MyRunnable1();
Thread T1 = new Thread(mr1,"Thread One");
Thread T2 = new Thread(mr1,"Thread Two");
Thread T3 = new Thread(mr1,"Thread Three");
T1.start();
T2.start();
T3.start();
System.out.println("Thread Main");
}
}
/*Scenario above includes synchronization of the run method. Output is:
"Thread Main" is first and with different permutations for the rests of the output.
Therefore can I safely say that the output cannot be determined for the programmer
threads. */
// MyRunnable2.java
// Testing the behaviour of concurrent threads using yield method.
// "Platform used in this test is the one that needs continuous rebooting."
public class MyRunnable2 implements Runnable{
public void run(){
Thread.yield();
System.out.println(Thread.currentThread().getName());

}
public static void main(String[] args){

MyRunnable2 mr2 = new MyRunnable2();
Thread T1 = new Thread(mr2,"Thread One");
Thread T2 = new Thread(mr2,"Thread Two");
Thread T3 = new Thread(mr2,"Thread Three");
T1.start();
T2.start();
T3.start();
System.out.println("Thread Main");
}
}
/*Scenario above calls yield() in the run method. Output is:
"Thread Main" is first and with different permutations for the rests of the output.
Therefore can I safely say that the output cannot be determined for the programmer
threads again as in Second scenario. */
// MyRunnable3.java
// Testing the behaviour of concurrent threads using join() method.
// "Platform used in this test is the one that needs continuous rebooting."
public class MyRunnable3 implements Runnable{
public synchronized void run(){

System.out.println(Thread.currentThread().getName());

}
public static void main(String[] args)throws InterruptedException{

MyRunnable3 mr3 = new MyRunnable3();
Thread T1 = new Thread(mr3,"Thread One");
Thread T2 = new Thread(mr3,"Thread Two");
Thread T3 = new Thread(mr3,"Thread Three");
T1.start();
T1.join();
T2.start();
T2.join();
T3.start();
T3.join();
System.out.println("Thread Main");
}
}
/*Scenario above calls join() in main method. Note run method is synchronized .
The call to join() follows start() of that thread.
Output is: "Thread One" "Thread Two" "Thread Three" "Thread Main"
as expected. */
// MyRunnable4.java
// Testing the behaviour of concurrent threads using join() method.
// "Platform used in this test is the one that needs continuous rebooting."
public class MyRunnable4 implements Runnable{
public synchronized void run(){

System.out.println(Thread.currentThread().getName());

}
public static void main(String[] args)throws InterruptedException{

MyRunnable4 mr4 = new MyRunnable4();
Thread T1 = new Thread(mr4,"Thread One");
Thread T2 = new Thread(mr4,"Thread Two");
Thread T3 = new Thread(mr4,"Thread Three");
T1.start();
T2.start();
T3.start();
T1.join();
T2.join();
T3.join();
System.out.println("Thread Main");
}
}
/*Scenario above calls join() for each thread after all threads have been started.
Output is: Different permutations for programmer threads first and then "Thread Main"
Therefore would it be safe to say that the order of the programmer threads cannot be determined and main will be last. */
regards,
Stephen
Stephen Batsas
Ranch Hand

Joined: Jan 22, 2002
Posts: 117
Its ok folks I have the thread behaviour under control.
Regards
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
I am transferring this discussion to Programmers Certification Study forum.


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Graeme Brown
Ranch Hand

Joined: Oct 13, 2000
Posts: 193
Don't assume anything about thread scheduling from tests run on a single machine. Thread scheduling is virtual machine dependent.
Gaurav Mantro
Ranch Hand

Joined: Sep 08, 2000
Posts: 61
Stephen.
Once you are done with your exam can you please take some time to share your analysis of thread functionlality with us. Seems like you have done lot of work to understand threads and it would be very useful to benefit from your notes and observations.


----------------------<br />regards.<br /><a href="http://www.mantrotech.com/editors/gaurav_mantro.asp" target="_blank" rel="nofollow">Gaurav Mantro</a><br /><a href="http://www.mantrotech.com/technology/java/index.asp" target="_blank" rel="nofollow">Java Information Portal</a> - <a href="http://www.mantrotech.com/technology/java/index.asp" target="_blank" rel="nofollow">http://java.mantrotech.com</a>
Rick Reumann
Ranch Hand

Joined: Apr 03, 2001
Posts: 281
My question about all of this is, what effect does labeling the run method synchronized have in these examples? It really wouldn't affect the behavior too much would it since there is no guarantee which Thread would be calling the synchronized run method next?
So first off is that a correct assertion?
My second question is since in these examples one instance of Runnable is being passed used for all the Threads, if you were to synchronize the run method would this prevent deadlocks if everything being done was contained within the run method? (The only way I could see it not preventing deadlocks would be if within the run method some other methods were called that spawned some Threads that might deadlock). This also would only seem to work when all the Thread instances were sharing the same Runnable instance. Am I totally off here?
Thanks for any feedback.
Bob Graffagnino
Ranch Hand

Joined: May 30, 2001
Posts: 81
In response to Rick's questions:
In this simle case, synchronizing the run() method will have no effect.
A programmer will generally synchronize the method of a shared object, not a method of a class that implements/extends a Runnable/Thread.
For instance, consider a husband and wife that have a joint bank account. The husband and wife are Thread objects and they both want to modify the shared object BankAccount. The bank account object could have synchronized methods like: deposit(int i), closeAccount(), and withdraw(int i). Synchronizing a method prevents the wife Thread from closing the account while the Husband is making a deposit. Or in other words, if one thread is using a synchronized method, another thread cannot call any synchronized methods of the shared object (BankAccount). Keep in mind that the CPU might tell the executing thread to stop what it's doing, so another thread can execute. Back to our analogy: The Husband thread is making a deposit (synchronized). Suddenly, the bank teller (the CPU) tells husband, "Stop what you are doing and go stand with all the other waiting customers. I promise I won't let anyone do any synchronized actions to your bank account until you are done." The bank teller then tells the wife thread to step up to the counter. The wife steps up and says, "I would like to close my BankAccount." The teller sees that the closeAccount() method is synchronized and the husband thread hasn't finished with the synchronized deposit() method, so he tells the wife thread, "I'm sorry, someone else is executing a synchronized method. Go stand with all of the other waiting customers." Had the wife asked the teller to execute a non-synchronized method of BankAccount (like getInterestRate() ), the teller would have permitted it. Eventually, the teller asks the husband thread to approach the counter and he finishes making a deposit, thus releasing the lock on BankAccount.
My point is that methods of a shared object generally will be synchronized instead of the methods of a thread class.

The second question was whether non-synchronized methods that happened to be spawned from a synchronized method could be called directly from multiple threads. Yes they can. The CPU won't check that far. It only knows that if one thread has a lock on a shared object, other threads cannot execute any synchronized methods on that object.
Stephen Batsas
Ranch Hand

Joined: Jan 22, 2002
Posts: 117
Thanks Guys for your input on this matter.
I am scheduled to sit the exam Feb 7 thursday.
Just one thing: The Bank example is wrong. When the husband goes to the bank to withdraw funds from the joint account - the wife has already cleaned out the account and closed it.
So much for marital sychronisation.
Regards,
Dorothy Finkel-Laverty
Ranch Hand

Joined: Nov 24, 2001
Posts: 51
No, Stephen, she just knows how to use the setPriority() method!
Thanks for your examples. They really cleared up some snarled thread concepts for me.
Good luck on Thursday.
[ February 05, 2002: Message edited by: Dorothy Finkel-Laverty ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Thread Behaviour? Help!!!
 
Similar Threads
doubt abt priorities in threads.......
Lock Mechanism Doubt
join()
How to make one thread die before another thread
join() method in Thread doesn't work as expected