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

threads and uncaught exceptions

 
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Question: If the main thread creates a new thread and that new thread throws an unchecked exception, does the program terminate or does the main thread continue with its work? Answer:

Question: If the main thread creates a new thread and the main thread throws an unchecked exception, does the program terminate or does the new thread continue with its work? Answer:

Lesson 1: If the exception is not caught by the time the run method completes abruptly then it is, by definition, an uncaught exception. At that point the thread that experienced the exception has terminated and the exception no longer exists. (TJPL 10.12)
Lesson 2: There is nothing special about the original thread-- it just happened to be the first one to get started for a particular run of an application, and it is treated just like any other user thread.
 
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Can we be absolutely sure that the behaviour of these code patterns is guaranted on every platform?




When the new Thread object referenced by t is put to runnable state, we have two threads: main() in running state with priority of 5, and t having priority of 5 because it inherits priority from main(). Now, the first question to ask is whether JVM selects to procede with run (and possibly finish it off), or continue with main(). I might be missing something essential about how main() thread is treated by JVM (please correct me), but if it's like any other thread, then the output may differ. The second question: will the overall behaviour remain the same if main() completes first?
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you Vad for reading my post. I like to share what I am learning. It is nice to know I am not talking to myself.


but if it's like any other thread, then the output may differ. The second question: will the overall behaviour remain the same if main() completes first?


Yes, the output may differ.
My output only shows one case. It shows what I would call the worst case. It shows that IF the new thread throws an exception early on, the main thread will continue with its business, sleeping and printing its name.
We might not want to generalize from one case. But this one case does demonstrate the general (overall) behavior/behaviour stated in TJPL.
If Java would print time in microseconds, we could get a better idea of what happens when. Milliseconds are just not very informative.
---- Just more boring details ...
When the main thread invokes start() and even before start() returns, the scheduler can choose to execute the new thread or continue executing the main thread.
So one possibility is the run() method is executed first. The new thread prints its name, throws an exception and dies. Then the main thread sleeps for 3 seconds, prints its name and dies.
Another possibility is the main thread sleeps for 3 seconds. Maybe in those three seconds, the Java virtual machine is swapped out and the underlying operating system executes other processes. The main thread completes, then the new thread executes run().
Another possibility is some byte codes of the main thread are executed, then some byte codes of the new thread are executed, the some more byte codes of the main thread are executed, et cetera.
Another possibility is both threads begin to run simultaneously in two different CPUs. The main thread sleeps and the new thread throws an exception in parallel.
I suspect what actually happened (the typical behavior/behaviour on my system) is that start() returned and the main thread invoked sleep. Then the new thread executed run() completely. On my system, after invoking start(), the main thread doesn't easily give up unless I add a Thread.yield().
[ October 06, 2003: Message edited by: Marlene Miller ]
 
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Marlene Miller:
It is nice to know I am not talking to myself.
[ October 06, 2003: Message edited by: Marlene Miller ][/QB]


Well most of the times what u say actually bounces above the general public's head.


When the main thread invokes start() and even before start() returns, the scheduler can choose to execute the new thread or continue executing the main thread.


Marlene r u sure about this statement. Once I had tested this by overriding the start() (and calling super.start()), and there was a huge sleep to avoid platform dependence. But the run() didn't start till the completion of start().
I don't remember, exactly how I had tested -> It was more like a blackbox testing and since then I had the impression that run() doesn't start unless the start method is exited.
Looking at the source code, start() is a native method, so doesn't help much in understanding the behaviour.
Could u please verify your statement ?
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Marlene r u sure about this statement.


Thank you for keeping my honest Gopal. No I am not sure. I have never seen the source code for a start method. Nor have my reliable thread sources ever said such.
I reasoned that start() schedules the new thread. Now that the queue of runnable threads has changed, the scheduler ought to reconsider who should be running. The scheduler ought to check whether the new thread has more reason to be running than the current thread.
In the end, it is only a guess based on how I would code it. I wouldn�t schedule a new thread and then ignore it. In a priority driven system, a lower priority thread ought to be swapped out immediately. In a time-sliced system, the time could be used up.
This is as close as I can come to trying to make it happen.

I tried running this in Forte. At t.start(), I step into. But I cannot tell for sure if run() is executed before start() returns.
In the future I will be more careful about qualifying what I say.
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Gopal,
Here is an experiment that suggests the 1st thread returns from start before the 2nd thread executes run.
t1 starts t2. In run(), t2 suspends t1 and gets the number of stack frames. After start(), t1 suspends t2 and gets the number of stack frames. run() executes first and t2�s frame count = 2. This tells me t2 has returned from start().
 
Gopal Shah
Ranch Hand
Posts: 65
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Marlene,
Probably u r correct (although u have used deprecated methods to prove something).
 
Marlene Miller
Ranch Hand
Posts: 1392
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I am not so sure now about how to interpret the results using the stack frame count. Maybe countStackFrames cannot count stack frames of native methods. I'll should look into that.
I am not worried about using deprecated methods. I think they were deprecated because of problems releasing locks. But I am not using locks.
 
I can't beleive you just said that. Now I need to calm down with this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic