This week's book giveaway is in the Spring forum.
We're giving away four copies of Spring in Action (5th edition) and have Craig Walls on-line!
See this thread for details.
Win a copy of Spring in Action (5th edition) this week in the Spring forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Bear Bibeault
  • Devaka Cooray
  • Liutauras Vilda
  • Jeanne Boyarsky
Sheriffs:
  • Knute Snortum
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Ganesh Patekar
  • Frits Walraven
  • Tim Moores
  • Ron McLeod
  • Carey Brown
Bartenders:
  • Stephan van Hulst
  • salvin francis
  • Tim Holloway

Threads question from Kahalid's exam..  RSS feed

 
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Q5. Given that a static method doIt() in a class Work represents work to be done, what block of code will succeed in starting a new thread that will do the work?


The correct answer is

I'm wondering how is the line 1 possible.. becoz runnable is an interface and cannot be instantiated... it can be an anonymous class.. but the 1st line shouldn't be possible...
Secondly.. for the wait() method.. when is an Interrupted Exception thrown..
 
Ranch Hand
Posts: 279
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
the anonymous class form is:
new (super class name) <(optional list of parameters)> {anonymous class that extends super};
so: new Runnuble() { //... }; is the declaration and instantiation of an anonymous class that extends Runnable, not initiating a Runnable object.
I'm not sure when a wait() method throws an Interrupted exception
HTH
 
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When a thread is in the waiting state and another thread interrupts it (saying enough sleep) using the interrupt method, the thread that was waiting sets its interrupt status and moves to the ready-to-run state. When the thread gets hold of the CPU again, it checks its interrupt status and because it was set its throws the interrupt exception and clears the interrupt status.
If a thread is running and gets interrupted, only its interrupt status is affected and won't throw the interrupt exception. The status is checked at the discretion of thread in this case and when this happens, the thread simply clears it.
Hope this help.
 
Alfred Kemety
Ranch Hand
Posts: 279
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


When the thread gets hold of the CPU again, it checks its interrupt status and because it was set its throws the interrupt exception and clears the interrupt status.


Many Questions here:
1- So what happens after throwing an interrupted esception? does the whole program terminate if the exception was not caught? or does the thread only terminates and another thread takes hold of the CPU?
2- What's the effect of interrupt() method? Why would another thread call it on another thread?


If a thread is running and gets interrupted, only its interrupt status is affected and won't throw the interrupt exception.


3- How would it get interrupted? Will another thread call the interrupt() method? How will this happen while the thread is actually in the running state, meaning no other thread is running.. or can 2 threads run at the same time? I don't think so....
Please explain
 
Shishio San
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


interrupt(), InterruptedException and other thread exceptions
If you look at the get() method, there is some exception handling code, due to the wait() method. When a thread is put in the wait() queue, conditions can occur that remove it from this queue. For example, there might be a situation where a thread is wait()ing, and another thread comes along and interrupt()s it. This can happen if a reference to the wait()ing thread is held in an object, and another thread runs through this object. This kind of behavor is useful when creating server side objects whose lifecycles you have to control. I will give examples of this in the next section. Now, the strange thing to remember is that when the wait()ing thread gets interrupt()ed, it resumes execution by throwing an exception in the code block of the wait() method. Once the InterruptedException is dealt with, the wait()ing thread is alive again, and if the exception is dealt with properly, should resume execution as it was intended, rather than just throwing an unhandled exception and freezing the thread. An example of this can be seen in the following example. This might be confusing if you are not that familiar with threads; things can get very confusing in your code, when a thread, which was created in one object, runs through other objects.
Let's say that the Consumer object has its own thread, and the Producer object has its own thread, and that they both share the Queue object. Now, after they are running for sometime, let's say that you want to shut down the Consumer, which might happen in a server side environment, where you might have to replace the Consumer with a different object (for example, if the class gets updated in a Servlet environment, or a new version of an object is deployed). In order to shut and take down this Consumer object at runtime, its thread has to be taken off of the wait()ing queue (if it is currently waiting). The best way to do this, is to have the server thread invoke a shutdown method of some sort on the Consumer object. The shutdown method should then invoke the interrupt() method on the Consumer's thread. Once this happens, an exception gets generated in the Queue's get() method (where the Consumer's thread was waiting). Phew! So, the Consumer's thread was interrupted in the Queue's get() method, and it returns null. The Consumer thread's run() method should have logic in it to determine when this has happened, and it should self terminate. Please note that complicated logic occurs because every thread has to have a run() method in which it all happens. This will be illustrated in the next section.

 
Shishio San
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Originally posted by Alfred Kemety:

3- How would it get interrupted? Will another thread call the interrupt() method? How will this happen while the thread is actually in the running state, meaning no other thread is running.. or can 2 threads run at the same time? I don't think so....
Please explain


Threads run concurrently
 
Shishio San
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A previous discusion on the same subject
 
Alfred Kemety
Ranch Hand
Posts: 279
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well I have a doubt about concurently, you mean 2 threads are running at the same time? in a multithreading envirnoment, or running in a multiprocessing envirnoment...
I think this point is not clear at all to me and it causes confusion when it comes to threads...
1- CPU - as I understand - can handle one process at a time, so if one thread has the CPU, another can't, unless you have multi-processor envirnoment? am I not right?
2- If a thread has the CPU then it's said to be in the running state, or does "running state" mean something else?
3- According to my understanding, there can't be 2 threads in the running state at the same time - meaning exact instance - in the JVM. Or can there be??
4- If all what I said is true, then you mean that a thread invokes interrupt() method on another thread while it's in the ready-to-run state and NOT in the waiting state or sleeping state or actually "Running" state, since both can't be "Running" at the same instance... is that correct?
by the way, the quote you included is for me, very confusing... maybe I should read it 2 - 3 more times....
[ October 24, 2002: Message edited by: Alfred Kemety ]
 
Shishio San
Ranch Hand
Posts: 223
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Alfred,


Well I have a doubt about concurently, you mean 2 threads are running at the same time? in a multithreading envirnoment, or running in a multiprocessing envirnoment...



Concurrently in this context means sharing the CPU. Only One thread is running at a time ( assuming that there's only one CPU)


1- CPU - as I understand - can handle one process at a time, so if one thread has the CPU, another can't, unless you have multi-processor envirnoment? am I not right?


That's right


2- If a thread has the CPU then it's said to be in the running state


That's right


3- According to my understanding, there can't be 2 threads in the running state at the same time


That's right


4- If all what I said is true, then you mean that a thread invokes interrupt() method on another thread while it's in the ready-to-run state and NOT in the waiting state or sleeping state or actually "Running" state, since both can't be "Running" at the same instance... is that correct?


Here's the confusion.
If you check the API about the interrup() method in the Thread class it says


interrupt
public void interrupt()Interrupts this thread.
First the checkAccess method of this thread is invoked, which may cause a SecurityException to be thrown.
If this thread is blocked in an invocation of the wait(), wait(long), or wait(long, int) methods of the Object class, or of the join(), join(long), join(long, int), sleep(long), or sleep(long, int), methods of this class, then its interrupt status will be cleared and it will receive an InterruptedException.
If none of the previous conditions hold then this thread's interrupt status will be set.


Okay Let me rephrase what i said:
I guess i made a mistake earlier on about the interrupt status. Anyways, it's clear from what it's stated above that the InterruptedException is thrown when the interrupt() method is called on a thread that is in a BLOCKING state.
Now when the thread is in the ready-to-run state and gets interrupted it will eventually stop running when it regains control of the CPU but won't throw the InterrruptedException. Moreover, the thread may not stop immediately when it gets to the running state, The JVM sets an internal flag (interrupt status) to indicate the thread has been interrupted and eventually the thread stops running.
I hope this is clearer.
 
Ranch Hand
Posts: 2120
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is nothing in the interrupt method that forces a thread to stop. It happens automatically only when the target thread is wating, joined or sleeping and the corresponding InterruptedException is not caugth.
If the the target thread is not waiting, sleeping or joined the interrupt method sets the interrupted status of the thread; the purpose is to permit the target thread to check this status via interrupted() or isInterrupted(), and then the thread exits via "return" for instance.
 
Saniya Ansari
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks you two.. if only i had checked these before i got similar questions on the exam and i think i got it wrong.. on both the topics can u beleive it... *sigh* never mind..thanks anyways and good luck
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!