• 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:

Please give me reply.

 
Ranch Hand
Posts: 130
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Ranch Hand
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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 ?

 
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 136
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
 
Suma Narayan
Ranch Hand
Posts: 136
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree with Tom. That's where I come from. Checkout that book he mentioned, I really liked it.
Ajith
 
Deepa sivasankar
Ranch Hand
Posts: 35
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 5782
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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
Posts: 18944
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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
Posts: 88
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Missing the expert on Threads the sheriff BIG DADDY
 
It's hard to fight evil. The little things, like a nice sandwich, really helps. Right tiny ad?
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic