This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Programmer Certification (SCJP/OCPJP) and the fly likes Please give me reply. 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 "Please give me reply." Watch "Please give me reply." New topic
Author

Please give me reply.

sreelakshmi sarma
Ranch Hand

Joined: Mar 02, 2000
Posts: 130
please give me confirmation regarding this threads question.
What might cause the current thread to stop executing.
A. An InterruptedException is thrown. //I think it is false. The thread won't stop executing.
B. The thread executes a wait() call.//true
C. The thread constructs a new Thread.
D. A thread of higher priority becomes ready.//true
E. The thread executes a waitforID() call on a MediaTracker.//true
Thanks.
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944

Sree:
Again, a previous discussion on the same question...
(boy I did a lot of searching for you today ... 3 qstns) http://www.javaranch.com/ubb/Forum24/HTML/000773.html
Also, you may find this intresting http://www.javaranch.com/ubb/Forum24/HTML/000655.html
And if you want more on stop() and yeild(), do this:
search with the following string "higher priority thread".
I got about 10 discussions regarding, when the currently
running thread will yeild() or stop().
Good discussions there...
Best of luck.
Regds.
- satya
Tom P
Ranch Hand

Joined: May 06, 2000
Posts: 88
You are correct about A. The thread could catch the exception and continue processing.
B is correct. A thread that releases the monitor in a synchronized method is placed in a blocked state. (A wait() can also cause an InterruptedException to be thrown.)
C will not stop execution. The new thread will sit as a newborn thread until a start() is applied to it. Once it is started it is runnable but not running.
D will not cause a thread to stop executing. All this means is that the higher priority thread will be given preference among the "runnable" threads. As long as the currently running thread does nothing to put itself into a blocked or runnable state, it will continue to run.
E. Although the waitForID() will cause the thread to go to blocked until the images are loaded, if the images are already loaded, the waitForID() will do nothing.
Deepa sivasankar
Ranch Hand

Joined: Jul 22, 2003
Posts: 35
In the above Tom's answer , the option D quoted below
"D will not cause a thread to stop executing. All this means is that the higher priority thread will be given preference among the "runnable" threads. As long as the currently running thread does nothing to put itself into a blocked or runnable state, it will continue to run."
Just a clarification that if a thread which is running (using cpu resources) will not be interrupted by the high priority thread, so ultimately the current running thread finshes what it is doing and the high priority thread gets a chance depending on the other threads in the runnable (ready ) state's priority. If this high priority's priority is high, then this will execute next.
Am i right ?. Can someone correct me ?

Suma Narayan
Ranch Hand

Joined: Apr 03, 2000
Posts: 136
Hi Deepa,
If this high priority's priority is high, then this will execute next.
Yes, you are right. If the thread's priority is highest among all thread's priority in the ready state, it will be executed first.
Note: If there are two threads with same highest priorty then there is no guarantee which one will be executed first.


[This message has been edited by Suma Narayan (edited May 16, 2000).]
Deepa sivasankar
Ranch Hand

Joined: Jul 22, 2003
Posts: 35
No Suma. my question was not that.
Assuming a thread A which is running now. Now a thread of highest priority B than the thread A comes in. What happens?.
My clarification was " Thread A finishes what it is doing and the highest priority thread B will be the one executed based on the other threads in the runnables state. If B has highest priority than all other threads in the runnable state,then B executes next.
My question was whether A stops and B will run since B has the highest priority than A or not.
Thanks for your help
Maha can you please clarify for me?.
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944

Deepa:
I am taking the liberty of replying .. hope you/Maha
don't mind ...
IMO, Thread A WILL NOT STOP even if another thread B
becomes high priority. Thread B will wait in the ready
state till
- Thread A finishes
- Thread A yields
- or something else causes Thread A to stop.
Atleast this is how RHE explains (as I understand) with
the pixcel rendering example in his book.
Regds.
- satya
Tom P
Ranch Hand

Joined: May 06, 2000
Posts: 88
This is correct. A thread that is currently running does not stop simply because a higher priority thread wants to run. The higher priority thread must wait in the "runnable" state until the currently running thread gives up control.
Suma Narayan
Ranch Hand

Joined: Apr 03, 2000
Posts: 136
Hi Deepa,
Just a clarification that if a thread which is running (using cpu resources) will not be interrupted by the high priority thread, so ultimately the current running thread finshes what it is doing and the high priority thread gets a chance depending on the other threads in the runnable (ready ) state's priority. If this high priority's priority is high, then this will execute next.
I am sorry, I missed the first part. My answer was for the highlighted part. I agree with satya and Tom.
A thread that is currently running does not stop simply because a higher priority thread wants to run. The higher priority thread must wait in the "runnable" state until the currently running thread gives up control.
Suma.
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782

Isn't Thread scheduling based on priority JVM dependant ?? Priorities only give relative weightage to threads whereas, the JVM implementer might choose to honor or ignore the priorities while writing the scheduler.
If the above argument is right, behaviour thread scheduling is something we cannot generalise atleast with regard to threads with different priorities, either running or waiting to run.
Any comments??
Ajith


Open Group Certified Distinguished IT Architect. Open Group Certified Master IT Architect. Sun Certified Architect (SCEA).
Suma Narayan
Ranch Hand

Joined: Apr 03, 2000
Posts: 136
Hi Ajith,
Before I answered the question, I assumed that it is preemptive scheduling which supports Thread priority. I know, we should not assume but it is one of those ambigious questions. I feel the question should have been:
A thread of higher priority becomes ready depending on underlying platform.
Whatever you are saying is perfectly true.
Here is the clip from Sun's Java tutorial, which I think is worth reading.
Understanding Thread Priority
Previously, this lesson claimed that threads run concurrently. While conceptually this is true, in practice it usually isn't. Most computer configurations have a single CPU, so threads actually run one at a time in such a way as to provide an illusion of concurrency. Execution of multiple threads on a single CPU, in some order, is called scheduling. The Java runtime supports a very simple, deterministic scheduling algorithm known as fixed priority scheduling. This algorithm schedules threads based on their priority relative to other runnable threads.
When a Java thread is created, it inherits its priority from the thread that created it. You can also modify a thread's priority at any time after its creation using the setPriority method. Thread priorities are integers ranging between MIN_PRIORITY and MAX_PRIORITY (constants defined in the Thread class). The higher the integer, the higher the priority. At any given time, when multiple threads are ready to be executed, the runtime system chooses the runnable thread with the highest priority for execution. Only when that thread stops, yields, or becomes not runnable for some reason will a lower priority thread start executing. If two threads of the same priority are waiting for the CPU, the scheduler chooses one of them to run in a round-robin fashion. The chosen thread will run until one of the following conditions is true:
A higher priority thread becomes runnable.
It yields, or its run method exits.
On systems that support time-slicing, its time allotment has expired.
Then the second thread is given a chance to run, and so on, until the interpreter exits.
The Java runtime system's thread scheduling algorithm is also preemptive. If at any time a thread with a higher priority than all other runnable threads becomes runnable, the runtime system chooses the new higher priority thread for execution. The new higher priority thread is said to preempt the other threads.

Rule of thumb:
At any given time, the highest priority thread is running. However, this is not guaranteed. The thread scheduler may choose to run a lower priority thread to avoid starvation. For this reason, use priority only to affect scheduling policy for efficiency purposes. Do not rely on thread priority for algorithm correctness.
This is the link.
http://java.sun.com/docs/books/tutorial/essential/threads/index.html
So, I am hoping that questions in real exam will not have any ambiguity. If the same question is framed in the exam, then probably I will not choose option D.
Suma.
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944

Ajith:
While the thread scheduling may be JVM dependent, the point
I am (and the rest) are trying to make is
"After a thread is run by the scheduler, it will not stop
and/or yield just because there is another thread waiting
in the pool."
Hope we are on the same page.....
Regds.
- satya
Tom P
Ranch Hand

Joined: May 06, 2000
Posts: 88
Well, the tutorial has to be taken with a grain of salt. According to the Sun book, "Concurrent Programming in Java" (published 2000), "... the scheduler is biased to prefer running [threads] with higher priorities. The exact policy may and does vary across platforms." As they say in this book, any application that requires priorities to run properly will not be portable.
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
I agree with Tom. That's where I come from. Checkout that book he mentioned, I really liked it.
Ajith
Deepa sivasankar
Ranch Hand

Joined: Jul 22, 2003
Posts: 35
Thanks suma,ajith,TOm and everyone for the reply.
So to conclude the final answer for D is true or false?
Thanks
Ajith Kallambella
Sheriff

Joined: Mar 17, 2000
Posts: 5782
I would say false.
I know, it is a conservative answer but I don't want to assume anything that is not stated in the question. Ofcourse, if the question referred to preemptive scheduling or platform independence, our choices would have been clearer.
Again, I am not disagreeing with the consensus here. All we have discussed in this thread are valid arguments. This is just my personal humble opinion.
The actual exam should not have ambiguity like this.....
Truly,
Ajith
Anonymous
Ranch Hand

Joined: Nov 22, 2008
Posts: 18944

Well....
1. If preemptive thread scheduler is specified ....
All of us agree (hopefully ) that 'D' is TRUE.
2. If time sliced scheduler .....
looks like this is where I have different opinion. Sorry...
Even in time sliced I would say YES. Please read ....
In a time sliced scheduler, hypothetically say the time
slicing (sampling or whatever) is 100 millisecs (any time).
Now out of all the threads, say one of the thread wins the
priority battle (with priority 7, meaning no other threads
in the pool have priority MORE than 7)and starts running.
Then another thread B gets a priority to say 9. In this
situation, as I understand, thread B should wait ATLEAST
100 millisecs (or whatever) to be able to RUN.
Hence IMHO, I think thread B is waiting, enven though it
has a higher priority.
Any comments....
Thanks.
- satya

Tom P
Ranch Hand

Joined: May 06, 2000
Posts: 88
Again to quote from the "Concurrent Programming in Java" book,
"Some JVM implementations map the ten Thread priorities into a smaller number of system supported categories so threads with different priorities may be treated equally. And some mix declared priorities with aging schemes or other scheduling policies to ensure that even low priority threads get a chance to run."
So the conclusion is that priorities alone can't tell you what behavior will occur in any particular implementation of the JVM.
Shashank Jha
Greenhorn

Joined: May 15, 2000
Posts: 9
Missing the expert on Threads the sheriff BIG DADDY
 
GeeCON Prague 2014
 
subject: Please give me reply.