aspose file tools*
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Will a started thread run to completion in this example? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Certification » Programmer Certification (SCJP/OCPJP)
Bookmark "Will a started thread run to completion in this example?" Watch "Will a started thread run to completion in this example?" New topic
Author

Will a started thread run to completion in this example?

Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Hi guys,

I read in K&S Study Guide - Chapter 9 Threads, page 714:

"And there is no guarantee that once a thread starts executing, it will keep executing until it's done. Or that a loop will complete
before another thread begins. No siree Bob. Nothing is guaranteed in the preceding code EXCEPT this: EACH THREAD WILL START, AND EACH THREAD WILL RUN TO COMPLETION".

I tried to understand this question that I found in K&S - Programmer Practice Exams:



What is the result? (Choose all that apply.)
A. Compilation fails.
B. No output is produced.
C. The output could be: "Andi Eyra "
D. The output could be: "Eyra Andi Eyra "
E. The output could be: "Eyra ", followed by an exception.
F. The output could be: "Eyra Andi ", followed by an exception.

The book said that E and F are the correct answers. I can see without problems option F, but not option E.

As the code stands, I think the possible output are:

"Eyra Andi ", followed by an exception. OR
"Andi Eyra", followed by an exception. OR
"Eyra", followed by an exception, followed by "Andi" OR
"Andi", followed by an exception, followed by "Eyra"

But, this one

E. The output could be: "Eyra ", followed by an exception.

is not possible because thread t1 has been started in the main thread before the IllegalThreadStateException is thrown, so t1 will always print "Andi". If we interchange in the main methods these two calls:

t2.start();
t1.start();

The option E would be a possibility.


Am I right? If not, the question that really worry me:

Is it guaranteed that the thread t1 "Andi" which has been started in main thread will run to completion as K&S wrote in their book?

Thanks in advance,

Alvaro


OCPJP 6 98%
Tommy Delson
Ranch Hand

Joined: Apr 13, 2011
Posts: 206
I think you didn't read the Thread chapter completely or fully understood, it won't be quick to grasp something like this quickly.

If you reread the chapter again you'll see and noticed that in the book also mentioned that the Thread doesn't start at all, there is no guaranteed. Therefore, option E is possible since t1 not even started. See below for insight...


E. The output could be: "Eyra ", followed by an exception.
new Race().go(t2); //This line will always executed and started the Thread and follow the exception until it reach "t2.start();" second call.

F. The output could be: "Eyra Andi ", followed by an exception.

t1.start(); //This line could execute FIRST or SECOND or WON"T execute at all.
t2.start(); //This line could execute FIRST or SECOND or WON"T execute at all.

Does it makes sense now?? Go back to the chapter and reread to reinforce your knowledge....you've missed many important points in the chapter.

To confirm and clear your doubt run many tests as possible, you'll see and understand Thread's behaviors.



OCPJP6-05-11
"Your life is in your hands, to make of it what you choose."
Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Thank you very much Tommy for your answer.

I read the chapter almost 5 times, and this evening one more time. I did several times all the questions in K&S - Study Guide, K&S - Programmer Practice Exams (not full exam III and IV, I wouldn't like to memorize the questions, so I will leave them for the last week before the exam), Khalid - Programmer Guide. I did several mock exams too, included in these books, plus, all Whizlabs and ExamLab, and honestly in the last couple of weeks I didn't make mistakes in thread questions.

But I made this one and I can't understand why.

What do you mean when you say:

t1.start(); //This line could execute FIRST or SECOND or WON"T execute at all.
t2.start(); //This line could execute FIRST or SECOND or WON"T execute at all.

Does this mean that the code in the main method is not executed sequentially?

All this calls are executed in the main thread:



Are not they executed in the main thread sequentially?

And when you say: "... the Thread doesn't start at all, there is no guaranteed" you mean, in general, there is not guaranteed that a thread will start after call its start() method, or just in this case?

I tried to find this affirmation in K&S - Study Guide and this is what I found:

Referring to this code (page 714 to 716):



Running this code might produce the following:
% java ManyNames
Run by Fred, x is 1
Run by Fred, x is 2
Run by Fred, x is 3
Run by Lucy, x is 1
Run by Lucy, x is 2
Run by Lucy, x is 3
Run by Ricky, x is 1
Run by Ricky, x is 2
Run by Ricky, x is 3

Well, at least that's what it printed when we ran it—this time, on our machine.
But the behavior you see above is not guaranteed. This is so crucial that you need
to stop right now, take a deep breath, and repeat after me, "The behavior is not
guaranteed." You need to know, for your future as a Java programmer as well as for
the exam, that there is nothing in the Java specification that says threads will start
running in the order in which they were started (in other words, the order in which
start() was invoked on each thread). And there is no guarantee that once a thread
starts executing, it will keep executing until it's done. Or that a loop will complete
before another thread begins. No siree Bob. Nothing is guaranteed in the preceding
code EXCEPT this:
Each thread will start, and each thread will run to completion.
Within each thread, things will happen in a predictable order. But the actions
of different threads can mix together in unpredictable ways


Later in the chapter:


Because it's up to the scheduler, and we don't control the scheduler! Which brings up
another key point to remember: Just because a series of threads are started in a
particular order doesn't mean they'll run in that order
. For any group of started
threads, order is not guaranteed by the scheduler. And duration is not guaranteed.
You don't know, for example, if one thread will run to completion before the others
have a chance to get in or whether they'll all take turns nicely, or whether they'll do
a combination of both. There is a way, however, to start a thread but tell it not to
run until some other thread has finished. You can do this with the join() method,
which we'll look at a little later.
A thread is done being a thread when its target run() method completes.


I couldn't find your affirmation in the chapter. Please, could you tell me where I can find it?

If your affirmation is correct I can understand the option E. But how is that possible? I mean, if you call once t1.start() how is it possible that the thread will not execute the code in its run() method? Is there any way to guaranteed that a thread will start and run to completion?

Thanks a lot for your time,

Alvaro

PS: I tried the code a lot of times (more than 200) and thread t1 "Andi" printed its name. Also I tried to give it lower priority and put it to sleep, but it always printed its name. I could only get the option E. The output could be: "Eyra ", followed by an exception. with this code:



I only exchanged the calls t1.start() and t2.start(). In this case, the exception is thrown before the call to t1.start(), so the option E is the most probably output.


Just to let you know, in your answer in this other thread http://www.coderanch.com/t/546414/java-programmer-SCJP/certification/Practice-Exams-book-Full-Exam you can see that the thread t1 "Andi" printed its name:

Result:

Exception in thread "main" java.lang.IllegalThreadStateException
Eyra Andi at java.lang.Thread.start(Unknown Source)
at Race.main(Race.java:10)



I have just googled and I have found this http://www.roseindia.net/java/thread/overview-of-thread.shtml

Just to highlight:

A process is an instance of a computer program that is executed sequentially...

A thread is a lightweight process...

In Java Programming language, thread is a sequential path of code execution within a program. Each thread has its own local variables, program counter and lifetime. In single threaded runtime environment, operations are executes sequentially... (My note: OK, in single threaded runtime environment, but if it is multithreaded, the sequences are mixed, but each thread keep its sequence)

When any standalone application is running, it firstly execute the main() method runs in a one thread, called the main thread. If no other threads are created by the main thread, then program terminates when the main() method complete its execution. The main thread creates some other threads called child threads. The main() method execution can finish, but the program will keep running until the all threads have complete its execution (My note: if they have been started...)

Just to have more information.
Tomasz Sochanski
Ranch Hand

Joined: Jan 13, 2009
Posts: 47

hi,

calling method Thread.start() puts thread into scheduler and changes its status to RUNNABLE (which doesn't mean that it is running - it means that thread is ready to run)
jvm's scheduler decides when and how long thread will be executed by CPU

in your code:


possible order of next steps could be:
- t2 is started from (1) (new thread stack is created, status is changed to RUNNABLE) - now both: t2 and main thread are RUNNABLE, but in this moment only main thread is executed by cpu
- scheduler keeps main thread running and t2 is started from (2) (new thread stack is created,status is changed to RUNNABLE) - now all: t1, t2 and main thread are RUNNABLE
- scheduler suspends main thread and takes t2 to runnig - gives it cpu, runs run() method which prints "Eyra" (yes, BEFORE bringing main thread to cpu and calling (3) in main() )
- scheduler puts t2 to TERMINATED state and brings thread with main() method to cpu
- (3) is called and exception is thrown

notice, that t1 was still waiting for its cpu time, t1.run() wasn't called yet - that's why answer "E" is correct


regards,
t.



Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Hi,




possible order of next steps could be:
- t2 is started from (1) (new thread stack is created, status is changed to RUNNABLE) - now both: t2 and main thread are RUNNABLE, but in this moment only main thread is executed by cpu
- scheduler keeps main thread running and t2 (I think you meant t1) is started from (2) (new thread stack is created,status is changed to RUNNABLE) - now all: t1, t2 and main thread are RUNNABLE
- scheduler halts main thread and takes t2 to runnig - gives it cpu, runs run() method which prints "Eyra" (yes, BEFORE bringing main thread to cpu and calling (3) in main() )
- scheduler puts t2 to TERMINATED state and brings thread with main() method to cpu
- (3) is called and exception is thrown

Ok, perfect, this is exactly my view point.

notice, that t1 was still waiting for its cpu time, but scheduler didn't give it yet, so answer "E" is correct

But has the program finished yet? The exception is thrown in the main thread, so if there would have been more code after the call t2.start() in the main method, that code would not be executed IN THE MAIN THREAD. The exception affects only to the main thread. But there is other thread alive, t1 "Andi", and as K&S wrote in their Study Guide (page 714 - 716):

...Nothing is guaranteed in the preceding code EXCEPT this:
Each thread will start, and each thread will run to completion.


So the thread t1 that was in runnable state will get its turn and it will print its name "Andi". So, in your example the output would be:

"Eyra " followed by the Exception "Andi "

Or maybe, with the word "Andi" in somewhere in the message of the exception, but "Andi " is printed, or not?
Tomasz Sochanski
Ranch Hand

Joined: Jan 13, 2009
Posts: 47

Alvaro San Millan wrote:

...Nothing is guaranteed in the preceding code EXCEPT this:
Each thread will start, and each thread will run to completion.


So the thread t1 that was in runnable state will get its turn and it will print its name "Andi". So, in your example the output would be:

"Eyra " followed by the Exception "Andi "

Or maybe, with the word "Andi" in somewhere in the message of the exception, but "Andi " is printed, or not?


you are absolutely right, t1 has to get it's chance and run to finish
I thought you are asking about order of execution and didn't notice that the problem is in finish running t1 thread
now I don't know how "E" could be possible (I guess that hardware crash is not a case ;)
Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Thanks Tomasz, you are the first guy who has seen my view point. I think is really important to be clear in this. Most of the people answered me about this question without any doubt, and that's why I am worry, because I am quite sure (but not 100%), that option E is not possible. But maybe I misunderstood something and I would like to know what.

So, could someone check this topic and tell us if we are right when we say that this option:

E. The output could be: "Eyra ", followed by an exception.

is not possible in this code:



I will really appreciate. Thanks a lot for your help guys.

Alvaro


PS: Just to be sure that all threads will run to completion after they have been started and they will execute its code sequentially (Andi will print Andi 0 to Andi 9, Bandi will print Bandi 0 to Bandi 9, and so on, but the order between threads is unpredictable:

dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Alvaro, I have the same confusion as you. I hope that the author will respond to this thread to clear up our doubts.
Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
I hope too, Dennis
Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Somebody who can clarify this topic???
Tommy Delson
Ranch Hand

Joined: Apr 13, 2011
Posts: 206
See my comments below for more info....hope it help.





Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Thanks Tommy for your quick answer. Please, could you read my questions/comments to your comments.
I wrote them in blue colour with (CAPITAL LETTERS) to find them easier.

public class Race
{
public static void main(String[] args)
{
Horse h = new Horse();
Thread t1 = new Thread(h, "Andi");
Thread t2 = new Thread(h, "Eyra");

new Race().go(t2); //(1) - This call will always execute first. (I AGREE)

t1.start(); // (2) - This call will execute second, but doesn't mean t1 thread is execute just t1 is alive in state of execution.
/(I AGREE, BUT IT IS IN THIS POINT WHERE I GET CONFUSED. THERE IS NOT
// GUARANTEED THAT IT WILL RUN IMMEDIATELY, BUT WILL IT RUN TO COMPLETION?
// IF YOUR ANSWER TO MY QUESTION IS YES, THE BIG QUESTION ABOUT IF THE OPTION "E"
// IS A POSSIBILITY CAN BE ANSWER RIGHT NOW:
//
// E. The output could be: "Eyra ", followed by an exception.
//
// I THINK THIS OPTION NEEDS THE WORD "Andi " SOMEWHERE IN THE OUTPUT TO BE CORRECT
// AM I RIGHT?


t2.start(); // (3) - This call will execute third, but doesn't mean t2 thread is execute just t2 is alive in state of execution.
// (I AM NOT SURE WHAT YOU MEANT WHEN YOU SAY ...just t2 is alive in state of execution.
// I THINK THIS IS THE CALL WHICH WILL THROW THE EXCEPTION, BECAUSE THERE HAVE ALREADY BEEN
// A CALL TO t2.start() (WELL, TO t.start()) IN THE METHOD go() IN (1)
// AM I RIGHT?)

}

void go(Thread t) // No LOCK is acquired for this method so, any thread can jump and interrupt t thread
{ // (I AGREE, BUT AS THE CODE STANDS THERE IS NOT A POSSIBLE INTERRUPTION
// AM I RIGHT?)


System.out.println("go before"); //This line execute sequentialy and print out

t.start(); // This line started the thread of execution, but not guaranteed it will run.
// (BUT WILL IT RUN TO COMPLETION?
// AM I RIGHT?)


System.out.println("go after"); //This line execute sequentialy and print out
}
}

class Horse implements Runnable
{
public void run()
{
System.out.print(Thread.currentThread().getName() + " ");
}
}

/*


1st run:

go before
go after
Eyra Exception in thread "main" Andi java.lang.IllegalThreadStateException
at java.lang.Thread.start(Unknown Source)
at Race.main(Race.java:10)


new Race().go(t2); //(1) - Execute first calling the go(t2) method

//(1a) - The go(t2) method is executed
//(1b) t.start(); - Could execute first or second or third or not executed at all.
// WHAT DO YOU MEAN WHEN YOU SAY: ... or not executed at all?
// IS THERE ANY POSSIBILITY THAT THE run() METHOD IN THREAD t2 "Eyra " WILL
// NOT BE EXECUTED?

//This thread guaranteed to execute only the go() method acquired a LOCK
//on the go() method with a Synchronized keyword. Otherwise, t1 or t2 code
//lines below run next.
// (I AGREE, BUT THE CALL TO t.start() IS DONE AT THIS POINT, SO
// THE THREAD t2 IS AN ALIVE THREAD AND IT WILL RUN TO COMPLETION
// AM I RIGHT?


t1.start(); //(2) - Execute first or second or third or won't execute at all.
t2.start(); //(2) - Execute first or second or third or won't execute at all.
// I AM SORRY TO REPEAT THE SAME QUESTION, BUT HERE I STILL
// CANNOT UNDERSTAND HOW A CALL LIKE t1.start() IN THE MAIN THREAD WILL
// NOT BE EXECUTED?
// ALL THESE CALLS ARE IN THE MAIN METHOD AND THEY WILL BE EXECUTED
// SEQUENTIALLY INSIDE THE MAIN THREAD WHEN IT IS RUNNING
// AM I RIGHT?


Based on the result above you can see that t2 is executed twice before t1 does. t2.start() or t.start()
execute FIRST and t1.start(); execute SECOND and print out "Andi" before the rest of exception message
print out.

So this conclude and confirm that:

E. The output could be: "Eyra ", followed by an exception.

(AND THIS IS WHAT I CAN NOT UNDERSTAND, IF THREAD t1 PRINTED OUT AS YOU SAID ABOVE (IN BOLD RED STYLE),
THE WORD "Andi " IS MISSING IN THIS OUTPUT, IT MUST APPEAR SOMEWHERE IN THE OUTPUT TO MAKE THE OPTION CORRECT.
AM I RIGHT?)


---------

2nd run:

go before
go after
Eyra Exception in thread "main" java.lang.IllegalThreadStateExceptionAndi
at java.lang.Thread.start(Unknown Source)
at Race.main(Race.java:10)

(THE WORD "Andi " APPEARS AGAIN IN THE OUTPUT)

- This scenario t.start() or t2.start() started first or second, and t.start() didn't start at all. From
this experiment you can confirm that no Thread is guaranteed to run.

(AS YOU CAN SEE IN THIS OUTPUT THREAD t2 PRINTED OUT ITS NAME "Eyra ",
THREAD t1 PRINTED OUT ITS NAME "Andi " TOO, AND THE MAIN THREAD HAS THROWN THE EXCEPTION)


---------

3rd run:

go before
go after
Eyra Andi Exception in thread "main" java.lang.IllegalThreadStateException
at java.lang.Thread.start(Unknown Source)
at Race.main(Race.java:10)


- In this case t.start() or t2.start() execute FIRST and followed t1.start(), and finally an exception
thrown by t.start() or t2.start().


---------
4th run:

go before
go after
Eyra Exception in thread "main" java.lang.IllegalThreadStateExceptionAndi
at java.lang.Thread.start(Unknown Source)
at Race.main(Race.java:10)

- This scenario similar to 1st run except the "Andi" print out in different place within the exception
message print out.

Because is no LOCK on an Object any thread can jump in and execute while other thread is running
(i.e t.start() or t2.start()) interrupted by t.start() despite the FACT that each thread will
run to it completion and it is in this case.
(I DO NOT REALLY UNDERSTAND WHAT YOU MEAN WITH THIS SENTENCE. I CAN SEE
THAT THE run() METHOD IS NOT SYNCHRONIZED, SO SEVERAL THREADS CAN JUMP IN AND EXECUTE
ITS CODE CONCURRENTLY, BUT WHAT YOU MEAN WITH THE REST OF THE SENTENCE PARTICULARLY
WHERE YOU HAS USED THE WORD "INTERRUPTED". IT IS NOT CLEAR TO ME.)



The running thread is interrupted by other thread, but it will running until complete it execution once
it has a chance enter the running state.

(WHEN YOU SAY "INTERRUPTED" YOU MEAN THAT THE RUNNING THREAD GOES TO RUNNABLE
STATE AND ANOTHER THREAD GOES TO RUNNING. AM I RIGHT?)


So this conclude and confirm that:

E. The output could be: "Eyra ", followed by an exception.


Recap from K & B book page 766.

Besides those three, we also have the following scenarios in which a thread might
leave the running state:

¦ The thread's run() method completes. Duh.
(OK, THAT MEANS THAT t1 WILL PRINT "Andi ")

¦ A call to wait() on an object (we don't call wait() on a thread, as we'll
see in a moment).
(OK, BUT IN THIS CODE THERE ARE NOT CALLS TO wait() ON ANY OBJECT)

¦ A thread can't acquire the lock on the object whose method code it's
attempting to run.
(OK, BUT THIS IS NOT POSSIBLE IN THIS CODE)

¦ The thread scheduler can decide to move the current thread from running
to runnable in order to give another thread a chance to run. No reason is
needed—the thread scheduler can trade threads in and out whenever it likes.
(OK, BUT ALL ALIVE THREADS WILL GET CHANCES TO RUN TO COMPLETION
AM I RIGHT?)


In summary, the thread scheduler is the controller that governs the execution
of threads in and out whenever it decided to. (I AGREE)

If you run the code above on different machine it will behaves and prints out results
differently. There is nothing in order to which thread will execute first, it depends on
the VM Thread Scheduler to chooses which thread to run. (I AGREE)




*/

Please, if you have time, could you clarify me these points?

Once again, thank you very much for your time. I have tried to explain myself as clear as I can. I am sorry if I did not write something incorrect, but English is not my tongue language

Tommy Delson
Ranch Hand

Joined: Apr 13, 2011
Posts: 206
I'm explained so clearly and fully on the topic, but seem like you haven't grasped the concept and understood it. I recommend go back to the Thread chapter reread it slowly with experiment by coding until you absorbed and understood the concept.

No matter how clearly and fully I explained you won't understand and see it make sense.

In summary, 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.

Based on an answers given by the question are possible answers that may apply, there could be more, but the author not tried to convey all there. You need to take an online mock test on Thread topic, from there you'll able to see Thread in different angle that may help you understand more about Thread.

It won't do any help if I explain more on Thread something that you haven't understand yet like a Doctor explain about the medical condition to a patient in term of technical. I'm sure the patient won't understood a word a Dr said until he/she have learned something about medical, and this is just scratch of the surface about medical that a patient tried to educate him/her self.

I'm sure you'll absorb it, but it take sometime. You need step out of the box (the book) and learn more about Thread from other sources that may help you learn better. There are a lot of good resources out there that will help you, think out side the box is the best way to solve the problem.

Hope it help...good luck.





dennis deems
Ranch Hand

Joined: Mar 12, 2011
Posts: 808
Tommy Delson wrote: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 this is truly the case then the statement on K&B p 714, already quoted by Alvaro, must be in error:

Nothing is guaranteed in the preceding code except this:
Each thread will start, and each thread will run to completion.


I think that's kind of the point of this thread. Can both statements be true? Do I need to go back and take Freshman logic again?
Paul Clapham
Bartender

Joined: Oct 14, 2005
Posts: 18651
    
    8

Alvaro, you are being far too logical here.

If your application starts a thread, then the operating system will execute that thread according to its rules. Which normally means that the thread will start running right away. But it's possible that the operating system is already running several threads which have higher priority than yours, so it won't start running your thread right away. Eventually your thread will run, when those higher-priority threads have gone away, but there isn't any guarantee about how long that will take. It could be seconds, or hours, or weeks, or longer.

So: yes, it's guaranteed that a thread will run. But it isn't guaranteed when that will happen, and it might never happen.
Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Thank you very much Paul and the rest of you for your opinions. Finally, I have understood it.

I am sorry for opening a new thread in other forum about the same topic, but I thought that "Threads and Synchronization" forum was more suitable for this question.

Summary:

Is it guaranteed that a started thread will run to completion?

As K&S wrote in their study guide:

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.


If your application starts a thread, then the operating system will execute that thread according to its rules. Which normally means that the thread will start running right away. But it's possible that the operating system is already running several threads which have higher priority than yours, so it won't start running your thread right away. Eventually your thread will run, when those higher-priority threads have gone away, but there isn't any guarantee about how long that will take. It could be seconds, or hours, or weeks, or longer.

Yes, it's guaranteed that a thread will run. But it isn't guaranteed when that will happen, and it might never happen.


So, the answer is NO.





Tommy Delson
Ranch Hand

Joined: Apr 13, 2011
Posts: 206
Paul has explained and said it all, hope that clear your confusion.

You can confirm that by coding, testing, and see how Thread behaves. Write and test many Thread programs as you can, from there you'll see whether it makes sense or not. No one able to convince you unless you have experienced yourself.

Yes, it's guaranteed that a thread will run. But it isn't guaranteed when that will happen, and it might never happen.


This meant maybe or maybe not the Thread is Running, in technical term Threads that run are in Runnable State not in Running State. Let's borrow a car as an analogy.

Let's

Car = Thread
VM Scheduler = You or Driver

Runnable and Running are totally different, think of Runnable as your Car is turn on, but put on Neutral or Park gear and waiting for the Driver or You to shift or change gear to drive to make your Car in Running or Rolling state so, you can drive it to point A to B.

If you or the driver don't Shift gear you car will never rolling or running despite it's in runnable state so the Thread. Does it make sense?

That elaborate the point Paul has stated and I tried to address.

See page 756 in K & B book on "Thread States and Transitions (Objective 4.2)" that explain all



I'm glad that finally you have understood something....


Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Thanks Tommy for the example. For me is clear now
Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Hi again,

When I was writing this thread I also asked this question in Oracle forums and I got a few answers. Check this link

http://forums.oracle.com/forums/thread.jspa?threadID=2260228&tstart=0

I think Paul is right in his comment in the context of the certification exam. But in real life, that situation is difficult to happen as some person affirms in the Oracle forums.

Once again, thanks for all your comments.
Emilio Rojas
Greenhorn

Joined: Nov 26, 2011
Posts: 6
I still have doubts about it.
If it's true that a thread could never start and the question was meant like that
then also Answer B ("No output is produced") should be a valid choice, right?

But only E and F are considered correct in the book.

I would really appreciate if one of the authors could clarify this

Thank you very much.
Alvaro San Millan
Ranch Hand

Joined: Mar 31, 2011
Posts: 36
Hi Emilio,

I was obsessive about this question. Paul Clapham clarified me the answer E when he wrote this:

If your application starts a thread, then the operating system will execute that thread according to its rules. Which normally means that the thread will start running right away. But it's possible that the operating system is already running several threads which have higher priority than yours, so it won't start running your thread right away. Eventually your thread will run, when those higher-priority threads have gone away, but there isn't any guarantee about how long that will take. It could be seconds, or hours, or weeks, or longer.

So: yes, it's guaranteed that a thread will run. But it isn't guaranteed when that will happen, and it might never happen.


To understand answer E we have to assume that "Andi" thread never happen, for example, assume that the operating system is running several threads which have higher priority than yours and your thread never have an opportunity to be executed. In fact, this is really difficult to happen with the modern operating systems, but for the propose of the exam it can happen. To be honest, I think that option B can be correct too if we make the same assumption.

Maybe someone else can clarify a little more.


Have a look this thread:

https://forums.oracle.com/forums/thread.jspa?threadID=2260228&tstart=0
Emilio Rojas
Greenhorn

Joined: Nov 26, 2011
Posts: 6
Anybody can help, please?

I'll do the exam on Wednesday and would really appreciate a definite answer

Many thanks
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Will a started thread run to completion in this example?