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
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Is Kathy Sierra right when she said "Each thread will start, and each thread will run to completion"

 
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Hi guys,

Someone wrote me this about threads:

"Thread running depends on the VM Scheduler and there is NO guaranteed a Thread will run and pick by the VM Scheduler despite you have started the Thread with a call x.start(). When you started the Thread it's just in a RUNNABLE STATE, reread the chapter until you fully understood"

(Chapter 9 Thread - Sun Certified Programmer for Java 6 - Study Guide (310-065) - Kathy Sierra and Bert Bates - 2008)

It is the red sentence that make me really confused. Actually, I read that chapter several times, and I could not read this kind of affirmation in all the chapter. What I could read is this,

From the book (pages 713 and 714)



And the authors wrote this:

Nothing is guaranteed in the preceding code EXCEPT this:

Each thread will start, and each thread will run to completion.



I try to explain myself, what I understood from the sentence in the book: Each thread will start, and each thread will run to completion

$java ManyNames

After this call, main method from the class ManyNames is invoked and the JVM execute the code in that method sequentially. When the main thread calls one.start(), the one thread (Java thread) is mapped with an Operative System thread (well, in most implementations), but the important thing, the one thread (Java thread) gets the RUNNABLE state waiting for a chance to get the RUNNING state an start the execution of the run() method of its target Runnable. So, at this point we have two thread that can be chosen to get the RUNNING state, main thread and the thread one. Assume main thread executes main method to the end. In this case, the calls two.start() and three.start() are invoked. Main thread finishes, and we have three alive threads waiting for its turn to get the RUNNING state. For me run to completion means that all these threads will print three times the sentence:

"Run by [THREAD NAME: Fred, Lucy or Ricky], x is [1, 2 or 3]"

And all of them will finish their run() method (AS THE CODE STANDS). One possible output could be:
Run by Fred, x is 1
Run by Lucy, x is 1
Run by Lucy, x is 2
Run by Fred, x is 2
Run by Lucy, x is 3
Run by Fred, x is 3
Run by Ricky, x is 1
Run by Ricky, x is 2
Run by Ricky, x is 3

But this order is not guaranteed.

So, my question is simple, if we execute THIS CODE (without any changed) in ANY Java Virtual Machine, is it GUARANTEED that all started threads (main thread, Fred, Lucy and Ricky) will run to completion OR I have to believe what the guy wrote me: there is NO guaranteed a Thread will run and pick by the VM Scheduler despite you have started the Thread with a call x.start()?

If what this guy said is correct, is it worth create and start a thread if there are not guaranteed that this thread will run to completion? Well, if it is a nice visual clock on the screen it does not matter if we can see the clock or not, but how about if it is a thread that control the emergency process in a factory, just an example.


Thanks for your opinions,

Alvaro

 
Ranch Hand
Posts: 180
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
The book differentiates between what you can expect in the exam and what you can expect in the real world.

For what you can expect in the exam, the book says:

The exam expects you to know what is and is not guaranteed behaviour so that you can design your program in such a way that it will work regardless of the underlying JVM. That’s part of the whole point behind Java.




For what you can expect in the real world, the book says:

Don't make the mistake of designing your program to be dependent on a particular implementation of the JVM. As you'll learn a little later, different JVMs can run threads in profoundly different ways. For example, one JVM might be sure that all threads get their turn, with a fairly even amount of time allocated for each thread in a nice, happy, round-robin fashion. But in other JVMs, a thread might start running and then just hog the whole show, never stepping out so others can have a turn. If you test your application on the "nice turn-taking" JVM, and you don't know what is and is not guaranteed in Java, then you might be in for a big shock when you run it under a JVM with a different thread scheduling mechanism.

 
Alvaro San Millan
Ranch Hand
Posts: 36
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
Thanks a lot for your comment. It is really useful.

Don't make the mistake of designing your program to be dependent on a particular implementation of the JVM. As you'll learn a little later, different JVMs can run threads in profoundly different ways. For example, one JVM might be sure that all threads get their turn, with a fairly even amount of time allocated for each thread in a nice, happy, round-robin fashion. But in other JVMs, a thread might start running and then just hog the whole show, never stepping out so others can have a turn. If you test your application on the "nice turn-taking" JVM, and you don't know what is and is not guaranteed in Java, then you might be in for a big shock when you run it under a JVM with a different thread scheduling mechanism.



I understood from the sentence in bold that a thread (in some Java Virtual Machine implementations) can get the running state and never step out. Well, I can think different possibilities that a thread will keep the CPU forever (in some Java Virtual Machine implementations), for example, a thread which target Runnable has an endless loop in its run() method. If this thread gets the running state in this kind of Java Virtual Machine implementations, it will keep the CPU forever.

So, there is not guaranteed that a started thread will run to completion in all Java Virtual Machine implementation.

Again, I repeat to myself

THERE IS NOT GUARANTEED THAT A STARTED THREAD WILL RUN TO COMPLETION IN ALL JAVA VIRTUAL MACHINE IMPLEMENTATIONS.

Well, but in MY EXAMPLE, can this situation happen? All the four threads (main thread, one, two and three) are FINITE. So, if one of these four threads, for example, thread "three" gets the running state in this kind of Java Virtual Machine implementations and keep the CPU so others can not have a turn, in some moment the thread "three" will finish its run() target method (in this example is only to print out a String) and it will leave the running state, so other thread can have a turn, and all of them will run to completion (in this example)

Am I right?
 
Marshal
Posts: 28193
95
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Report post to moderator
That's the same question as in your other long-running post. So I will close this one.
    Bookmark Topic Watch Topic
  • New Topic