Regarding Threads

[Joseph Fernando]

I know that this question relates to Suspend, Resume which
has been deprecated and does not figure in the JCP exam but
I came across this code in a mock exam.
class Threadex extends Thread
{
public void run()
{
System.out.println(" before suspends");
suspend();
resume();
System.out.println(" after resume");
}
public static void main(String args[])
{
Threadex a = new Threadex();
Thread t = new Thread(a);
t.start();
}
}
According to me the output for this code should be
'before suspends'
and the program should get suspended.
But in reality the output is
'before suspends'
'after resume' and the program terminates.
Could someone explain how do i suspend the 'Thread t'.

Thanks
Joseph

[prasanthi kothapa]

hi joseph,
the thread has only been suspended, it goes into the wait()
state.hence on calling resume() it comes back to the ready
state,it continues from where it got suspended.

hope it helps
bye ..
prasanthi

[Joseph Fernando]

Hi Prasanthi,
Thanks for your view. But the doubt persists in my mind
as to how can the thread call resume on itself when
it is suspended.
Thanks
Joseph

Originally posted by prasanthi kothapa:
hi joseph,
the thread has only been suspended, it goes into the wait()
state.hence on calling resume() it comes back to the ready
state,it continues from where it got suspended.

hope it helps
bye ..
prasanthi

[Ajith Kallambella]

Joseph,
Think of these methods as signalling operations which shout for the attention of thread scheduler. A thread object is just like any other object, but it communicates with the thread scheduler( a native program which is vendor dependent )
When you call <code>suspend() ( or resume() or wait() or notify() or notifyAll() or stop() or interrupt() </code> etc ) internally a flag is set indicating the state change. The "big-brother" (aka thread scheduler ) who is watching all the members of his family( all reachable thread objects ) makes note of this state change and initiates an appropriate action - like removing the thread from the running pool and adding it to the waiting pool, or the other way around as the situation may be.
It is really important to remember merely calling these methods will not guarantee an immediately observable behaviour. Since everything depends on the thread scheduler you should look at all of these transitional methods as state-setters. And when you do, a suspended thread calling <code>resume()</code> on itself isn't really such a big deal. It is just another plain-vanilla method call!!
HTH
Ajith

[Sasikanth Malladi]

Guys, I agree with Joseph. I ran a program exactly like this one (which I too got from a mock exam) and it produced "before suspends" and crashed ( I had to hit Ctrl+C) to get back the command line.
And logical explanations?
Shashi