Home arrow static arrow Java Programming [Archive] - Stack Overflow Error
Warning: Creating default object from empty value in /www/htdocs/w008deb8/wiki/components/com_staticxt/staticxt.php on line 51
Java Programming [Archive] - Stack Overflow Error
This topic has 62 replies on 5 pages.    « Previous | 1 | 2 | 3 | 4 | 5 | Next »

Posts:18,384
Registered: 21.03.00
Re: Stack Overflow Error  
Aug 7, 2004 1:55 PM (reply 45 of 62)



 
Ah, yes, that old trick, perpetrated by bugs through
the ages--hide when the print statements or debugger
show up. I think they learned it from Schroedinger's
cat.

What old trick are you referring to? I can't tell
which post this is a reply to.

Thanks

Hi, that is a reply to:

Yeah, I know. I'm not smothering it. It's just that since I added the try/catch code, I havn't yet
reproduced the error.... It's running as I type...

/Kaj
 

Posts:18,384
Registered: 21.03.00
Re: Stack Overflow Error  
Aug 7, 2004 1:57 PM (reply 46 of 62)



 
I actually thought it was clean, though I don't have that much experience with Java threads and
wasn't aware of the significant overhead involved in creating new ones. I suppose instead of letting
the thread die and creating a new one, I could call wait() and notify(). Do you consider that a better
alternative?

That's alot better.

/Kaj
 

Posts:8,813
Registered: 10/4/00
Re: Stack Overflow Error  
Aug 7, 2004 2:01 PM (reply 47 of 62)



 
The old trick is that the problem doesn't show up when you use the debugger or put in debugging statements. This is especially true of threaded code. For example, the time spent printing or manually stepping through the code can mask the problem.

Try putting this in your Runnable class
boolean isRunning=false;<...other code...>public void run() {    if (isRunning) System.out.println("You should never see this");    isRunning=true;    <...other code...>    isRunning=false;}


... I suppose instead of letting the thread die and
creating a new one, I could call wait() and notify().
Do you consider that a better alternative?

The code I was objecting to was
mThread = new Thread(this);
This creates a new thread using the existing Runnable object. You really have no idea what state the existing Runnable is in when you call this statement.
 

Posts:18,384
Registered: 21.03.00
Re: Stack Overflow Error  
Aug 7, 2004 2:15 PM (reply 48 of 62)



 
Hi bbritta,

The code I was objecting to was..
But I objected to the creation of lots of short lived threads. I said it should be better it if he kept them alive.

/Kaj
 

Posts:340
Registered: 7/8/04
Re: Stack Overflow Error  
Aug 7, 2004 2:16 PM (reply 49 of 62)



 
The code I was objecting to was
mThread = newThread(this);
This creates a new thread using
the existing Runnable object. You really have no idea
what state the existing Runnable is in when you call
this statement.

Just to clarify, you do NOT have a problem with the creation of the new threads themselves? Kaj (above) says that using wait() and notify() is much better.

Because couldn't your objection to not knowing the state of the Runnable object be answered by having the start() method (see original post) call a stop() method as its first line of code. The stop() method would ensure that the old thread was dead before creating the new one. Assuming that the run() method contains a while() loop controlled by the member variable mStopped (ie, "while (!mStopped)..."), your stop method could look like this:
public void stop() {  mStopped = true;  mThread.join();}

The reason I like having the thread itself contained in the runnable object is that it means client code doesn't have to deal with thread creation. It can just creat the Runnable object and call start() and stop() on it. That was my thinking, anyway. Any additional thought?

Thanks again,
John
 

Posts:18,384
Registered: 21.03.00
Re: Stack Overflow Error  
Aug 7, 2004 2:23 PM (reply 50 of 62)



 
Hi,

If you keep the threads alive, you doesn't have to think about creating new runnables :)
It's usually better to keep the threads alive, if you just want to re-start them later. And in your case you have mentioned that it is for a game. And I guess that the game has a life cycle that is repeated. starting -> playing game. -> game over - > staring -> ...

That indicates that you should keep your threads alive.

/Kaj
 

Posts:8,813
Registered: 10/4/00
Re: Stack Overflow Error  
Aug 7, 2004 2:27 PM (reply 51 of 62)



 
The creation of short lived threads is a separate issue. It might be bad or it might be good. I would object to creating a lot of them in a short time just to do some trivial task, but it's not necessarily a bad thing all by itself. You seem to be doing some kind of game. If you have bullets, I might object to creating a new thread for each bullet so that you could track it's trajectory. There's probably too many bullets and their life is too short. it isn't worth the overhead. On the other hand, if you had a game where you wanted to wait for 10 seconds after clicking on the 'chicken gun' for it to start firing and you wanted to use a thread for the wait and the firing and to have it stop after 3 seconds, I might not object to that unless there were several dozen 'chicken guns'

The answer to that is 'it depends'.
 

Posts:8,813
Registered: 10/4/00
Re: Stack Overflow Error  
Aug 7, 2004 2:34 PM (reply 52 of 62)



 
The reason I like having the thread itself contained
in the runnable object is that it means client code
doesn't have to deal with thread creation. It can just
creat the Runnable object and call start() and stop()
on it. That was my thinking, anyway. Any additional
thought?

I'm not totally against it. It just scares me when i see code like that. You have to understand the ramifications and code for them. It can make debugging horrific. especially on the java forum. We really can't debug your code unless we have the exact code you are running to test. Threading problems are incredibly hard to solve on a theorectical basis.
 

Posts:340
Registered: 7/8/04
Re: Stack Overflow Error  
Aug 7, 2004 2:59 PM (reply 53 of 62)



 
I'm not totally against it. It just scares me when i
see code like that. You have to understand the
ramifications and code for them. It can make
debugging horrific. especially on the java forum. We
really can't debug your code unless we have the exact
code you are running to test.

Point taken. Many thanks to you, Kaj, and everyone else for their input.

Of course, my app continues to run without error for coming on 90 minutes now. So who knows what the original problem was. In any case, I learned many useful things.

John
 

Posts:37,103
Registered: 3/30/99
Re: Stack Overflow Error  
Aug 7, 2004 3:10 PM (reply 54 of 62)



 
Ah, yes, that old trick, perpetrated by bugs through
the ages--hide when the print statements or debugger
show up. I think they learned it from Schroedinger's
cat.

What old trick are you referring to? I can't tell
which post this is a reply to.

It was just a smartass comment on "It's just that since I added the try/catch code, I havn't yet reproduced the error."
 

Posts:37,103
Registered: 3/30/99
Re: Stack Overflow Error  
Aug 7, 2004 3:19 PM (reply 55 of 62)



 
The code I was objecting to was
mThread = newThread(this);
This creates a new thread using
the existing Runnable object. You really have no idea
what state the existing Runnable is in when you call
this statement.

I don't necessarily see a problem with having a Runnable with a start ethod that delegates to a Thread--I do it from time to time. I'd have the Thread be a private final field though, not created during the call to start().

I don't think this is at the root of the stack overflow, but it does seem like slightly weird design.
 

Posts:340
Registered: 7/8/04
Re: Stack Overflow Error  
Aug 7, 2004 3:40 PM (reply 56 of 62)



 
have the Thread
be a private final field though, not created during
the call to start().

Good point. I should make that change.

I don't think this is at the root of the stack
overflow, but it does seem like slightly weird design.

Why is this design weird? It just removing the responsibility of thread creation from any client classes. That's why I did it, anyway.

John
 

Posts:37,103
Registered: 3/30/99
Re: Stack Overflow Error  
Aug 7, 2004 3:56 PM (reply 57 of 62)



 
Why is this design weird? It just removing the
responsibility of thread creation from any client
classes. That's why I did it, anyway.

Mainly bcause I can call start() on your Runnable over and over again, and, as bbritta said, you don't know what state the Runnable will be in when you do. Now, you said that you make sure the Runnable finishes up before you restart it with a new thread, but I think that rsponsibility belongs outside the Runnable.

JMAO

 

Posts:37,103
Registered: 3/30/99
Re: Stack Overflow Error  
Aug 7, 2004 3:58 PM (reply 58 of 62)



 
If you make the Thread a private final field, and don't reuse the Runnable, but just use the start method as convenience to delegate to the Thread, then I have no problem with it.
 

Posts:179
Registered: 7/30/04
Re: Stack Overflow Error  
Aug 7, 2004 4:44 PM (reply 59 of 62)



 
This creates a new thread using the existing Runnable object. You really have no idea what state the
existing Runnable is in when you call this statement.

Just some thought about threads and the "State of Runnable":

What you refer to as the "State of the existing Runnable" would refer to the state of the currently runnig thread. This state is actually encapsulated inside the Thread object, and not inside the object (or class) implementing the Runnable interface.

Adding the Runnable interface to a class that do not extend Thread does only "publish" the run() method so that a Thread instance can execute this method.

This leads to the ultimate point that if your custom class start() method is in fact able to execute the statement
mThread = new Thread(this);

then the state of the "current runnable" (or the current thread) must be active. If the current thread had died, it would not have at all execute the said statement.
 
This topic has 62 replies on 5 pages.    « Previous | 1 | 2 | 3 | 4 | 5 | Next »