• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

Thread Behaviour? Help!!!

 
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Its ok folks I have the thread behaviour under control.
Regards
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I am transferring this discussion to Programmers Certification Study forum.
 
Ranch Hand
Posts: 193
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Don't assume anything about thread scheduling from tests run on a single machine. Thread scheduling is virtual machine dependent.
 
Ranch Hand
Posts: 61
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 281
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 81
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 117
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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,
 
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ]
 
Get off me! Here, read this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic