• Post Reply Bookmark Topic Watch Topic
  • New Topic

Doubt in join().....

 
p anish
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
please help me in understanding this code...

The output i get is ..

one : true
one Running
one Running
one Running
one Running
one Running
one : false
one : true

my doubt is why is it not showing any exception when we call j1.start() for the second time....

please help....

[added [code] tags - Jim]
[ September 21, 2005: Message edited by: Jim Yingst ]
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your first call to j1.isAlive() can return either true or false. Thread.start() returns immediately. The new thread is not necessarily running yet.

Your second call to j1.isAlive() is guaranteed to return false as it occurs after a join statement which ensures the thread has exited. This also applies to your second start() statement which is guaranteed to occur when the thread is not running. I guess its on to restart a thread, but not call start while it is still running. If this is true the spec is poorly worded.

Your third call to j1.isAlive() again can return either true or false. We can't use its value to let us know if the thread ran or not, but the output lacking another set of 5 "Running" statements would indicate it did not.


what JVM are you using? This seems like an error on the JVMs part.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[Lamont]: Your first call to j1.isAlive() can return either true or false. Thread.start() returns immediately. The new thread is not necessarily running yet.

Not according to the API. After start() returns, the thread may not be running, but it has been started. This isAlive() is required to return true (unless of course the thread has already completed). Have you observed behavior to the contrary?

[Lamont]: This seems like an error on the JVMs part.

I seem to remember seeing a bug report about this - some older JVMs failed to throw IllegalThreadStateException for a second start(), under certain circumstances. I think it was supposedly fixed either in 1.4 or 1.5. Unfortunately I can't find the pertinent bug report. And of course, there may be some new bug instead.
[ September 21, 2005: Message edited by: Jim Yingst ]
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting. The API does not specify if a thread is considered 'started' once the call to start returns, or once it begins execution.
 
Jason Bourne
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The question remains as to what 'start' means. According to the API, for start() method, start means beginning execution. And isAlive() method checks if the method has started and is not yet dead. So the first statement to check the thread state can be either true or false, as Lamont has previously said. I dont agree with the sheriff on this. Pls clarify if u r v.sure of urself.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Mr Always,

Welcome to JavaRanch!

First, a bit of business: you may not have read our naming policy on the way in. It requires that you use a full, real (sounding) first and last name for your display name. Joke names, "handles", and obviously fake names don't work at JavaRanch. You can change your display name here. We take this rule rather seriously. Thanks!

Second, when you have a chance, you might want to read this document. It will help you communicate with our international audience.

Finally, regarding your question: if something's not explicitly stated in the API documentation, and it's not in the JLS nor the JVMS, then it's undefined, and here I think Jim was just making an educated guess. Whether the term "started" means the same thing as "start() has been called" is open to interpretation.

I went and looked at the (admittedly very old) Sun JVM source that I have, and what I found does actually supports Jim's guess. In the JVM I examined, anyway (1.0!) the native method implementation of isAlive() won't return "true" until the native thread is actually created and recorded inside the Java Thread object, because the native method that implements start() doesn't set the flag that isAlive() checks until it's ready to exit. But you can't actually say that start() has been called until start() returns, right? And when start() returns, that flag is set. But if start() is still executing, isAlive() returns false.

The implementation could avoid a possible race by having isAlive() be synchronized; I'm not sure why it's not.
[ October 06, 2005: Message edited by: Ernest Friedman-Hill ]
 
Henry Wong
author
Sheriff
Posts: 22542
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by JLearner Always:
The question remains as to what 'start' means. According to the API, for start() method, start means beginning execution. And isAlive() method checks if the method has started and is not yet dead. So the first statement to check the thread state can be either true or false, as Lamont has previously said. I dont agree with the sheriff on this. Pls clarify if u r v.sure of urself.


I don't think there is anything fancy done here -- the isAlive() method merely returns a flag. This flag is set to alive somewhere during start(), and set to not alive, somewhere in the cleanup code.

So yes, after the start() method has been called, but before the thread has started, the isAlive() method should return, albeit incorrectly, that the thread is alive.

Henry
 
Henry Wong
author
Sheriff
Posts: 22542
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Finally, regarding your question: if something's not explicitly stated in the API documentation, and it's not in the JLS nor the JVMS, then it's undefined, and here I think Jim was just making an educated guess. Whether the term "started" means the same thing as "start() has been called" is open to interpretation.


Yup... standard Caveat applies here.

My last answer may not be true for you particular JVM, or a future JVM.

Henry
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Im willing to bet the symantecs of thread state is speeled out in the JLS. Im too lazy to read it. Still the API documentation leaves a lot to be desired.
 
Jason Bourne
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am sorry i am still not quite convinced. A call to the start() method merely puts the thread in the runnable state from the ready state. Not in running(executing).So after start() returns, it is still possible that the thread is not actually executing. So the isAlive() will return false as it checks only for execution of the thread on which it is called. As per java 1.4.2 api reference available at this page. But i am most probably wrong. Correct me please.

And Mr.Hill, sorry about the name and my language. I obviously made the mistake of not reading the rules.
 
Vinod John
Ranch Hand
Posts: 162
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:

The implementation could avoid a possible race by having isAlive() be synchronized; I'm not sure why it's not.


How will there be a race condition ? How syncronizing isAlive() help it ?. Can you please explain ?.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vinod John:


How will there be a race condition ? How syncronizing isAlive() help it ?. Can you please explain ?.


start() is synchronized, but isAlive() is not. The native code in start() sets up the native thread, then sets a flag that says the thread is alive. It would therefore be possible to call start() in one thread, and isAlive() in another thread, and have isAlive() return false, even though the native thread had been created, if isAlive() is called before start() sets the flag and returns. This could be prevented by also making isAlive() synchronized. Obviously not a major point, but sometimes these minor details matter -- or we wouldn't be having this discussion!
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24213
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Jason Bourne:
I am sorry i am still not quite convinced. A call to the start() method merely puts the thread in the runnable state from the ready state. Not in running(executing).So after start() returns, it is still possible that the thread is not actually executing. So the isAlive() will return false as it checks only for execution of the thread on which it is called. As per java 1.4.2 api reference available at this page. But i am most probably wrong. Correct me please.


But as I said, I looked at the actual native source code for start() and isAlive(), and reported that isAlive() is merely checking a flag set by start(). start() sets this flag just before returning, after creating the native thread. What happens in the native thread -- i.e., whether run() has been invoked or not -- actually has nothing to do with it. So it appears that "started" in the isAlive() Javadocs means something closer to "runnable", not "running".

Furthermore, I don't believe the JLS defines "running" as having entered but not exited the run() method. The native thread will be running -- albeit for a very short time -- before run() is entered, because some code from the Thread class will invoke your run() method. At a minimum, that code contains a try block so that exceptions on the thread can be caught and their stack traces printed.
 
Henry Wong
author
Sheriff
Posts: 22542
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Vinod John:

How will there be a race condition ? How syncronizing isAlive() help it ?. Can you please explain ?.


The isAlive() method, or any status returning method, has a race condition in that the result is only valid at the time that the flag is read or calculated. This means that there is a "race condition" on when it is read or calculated.

Unfortunately, synchronizing the method does *not* solve the problem. All it does is change it from "valid at the time that the flag is read" to "valid at the time just before the method returns". There is still no guarantee that the result is valid at the time it is used. In general, this is not really a problem, as many designs doesn't depend on it. And these types of methods are only synchronized, if there is a race condition that can affect the accurate calculation of the flag itself.

Henry
 
Henry Wong
author
Sheriff
Posts: 22542
109
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But as I said, I looked at the actual native source code for start() and isAlive(), and reported that isAlive() is merely checking a flag set by start(). start() sets this flag just before returning, after creating the native thread. What happens in the native thread -- i.e., whether run() has been invoked or not -- actually has nothing to do with it. So it appears that "started" in the isAlive() Javadocs means something closer to "runnable", not "running".


Yea... It is hard to debate against code...

BTW, this is still true that last time I check about a year ago. It merely checks a flag that is set somewhere when calling the start() method.

And Jason... is your name really Jason Bourne? Boy, you parents must be diehard Robert Ludlum fans.

Henry
 
Jason Bourne
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks guys.... Now i understand threads better. And Mr.Wong, I am a Ludlum fan.
 
Mr. C Lamont Gilbert
Ranch Hand
Posts: 1170
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Race condition is a valid point. It puts isAlive up there with suspend and stop. Its not unsafe, but its useless. Thread state is not entirely relevant. But the state of the action taking place in the run method may be. Youll have to set and check your own variables.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!