How to test if thread is finished?

[Jan Liße]

Hi all,

I have a background network (in a seperate class) thread running that runs
only once and
waits for a tcp-connection, and finally should return a socket-object of the
connection. I have two
questions: what is the best way to return the socket-object and how can i
signalize or test that the
network-thread is finished with its work? At the moment i try within my
gui-class:
(while thread.isAlive)
{
textfield.setText = "Please wait for connection...";
}
But my textfield isnt updated and my gui-window hangs up too...

Thanks in advance,
Jan

 

[Gordon Beaton]

I have a background network (in a seperate class) thread running
that runs only once and waits for a tcp-connection, and finally
should return a socket-object of the connection. I have two
questions: what is the best way to return the socket-object and how
can i signalize or test that the network-thread is finished with its
work? At the moment i try within my gui-class:

(while thread.isAlive)
{
textfield.setText = "Please wait for connection...";
}
But my textfield isnt updated and my gui-window hangs up too...

There are most certainly issues with invoking long running tasks in
GUI event threads, but since I'm not a GUI programmer I'll let someone
else address those.

In the general case however, there is little point in starting a
separate thread if you simply wait until it's finished performing its
task. When there is no concurrency involved, you're usually better off
doing the task in the original (calling) thread itself.

However there are at least two feasible ways to synchronize the two
threads:

1. use t.join() in the calling thread to block until the other thread
is finished.

2. use o.wait() in the calling thread. It will block until the other
thread calls o.notify(), for example after the connection has been
made. o can be any object that both threads have access to.

/gordon

 

[SPG]

Hi,

You could use a callback method from your thread to notify you when
complete:

public class Test implements ThreadListener{
public Test(){
}

public void perform(){
Thread t = new Worker(this);
t.start();
}

public void threadComplete(Object someResult){
System.out.println("Thread Complete: " + someResult);
}
}


public interface ThreadListener{
public void threadComplete(Object someResult);
}

public class Worker extends Thread{
private ThreadListener theListener;
public Worker(ThreadListener listener){
super();
this.theListener = listener;
}

public void run(){
//DO SOME WORK
Object resultingObject = new String("HELLO");
//WHEN COMPLETE:
if( this.theListener != null){
this.theListener. threadComplete(resultingObject);
}
}

}

 

[Jan Liße]

Yes, thank you that is exactly what i need!
Now i know also why my gui hangs, it's just silly to do intensive tasks in
Listener methods
of the gui, because it brings the separetly running gui-thread to hang.
Jan

 

[SPG]

No Problem.
I know what you mean. I was always wondering why my GUI was hanging even
when running from threads.
The listener callback pattern is great and should solve your problem nicely.

You may want to extend it to be able to stop the thread if need be, add
another interface to expose a stopProcessing() method and listen for that in
your thread.

Have fun!

 

[Thomas Weidenfeller]

I have a background network (in a seperate class) thread running that runs
only once and
waits for a tcp-connection, and finally should return a socket-object of the
connection. I have two
questions: what is the best way to return the socket-object and how can i
signalize or test that the
network-thread is finished with its work?

The most elegant technique I am aware of is called a Future. A Future is
an object which is returned by an asynchronous method. The method
returns the Future as soon as possible, while internally starting a
thread which will produce the result at some point in time.

The Future serves as a placeholder for the result until it is available.
The Future object provides a few methods to check the status of the
available result, to synchronize and wait for the result, or to
cancel/drop the result.

Since Futures are normal objects, you can pass them around as you like,
until the point comes where you absolutely need the result from the
original method invocation. At that point you try to read from the
Future. If the result is available, you get it, otherwise
synchronization with the background thread of the asynchronous method
kicks in, and you are put on hold until you have a result.

/Thomas

 

[Jon A. Cruz]

Yes, thank you that is exactly what i need!

Actually, there are subtle problems with it. It's close, but there are
better solutions.

Now i know also why my gui hangs, it's just silly to do intensive tasks in
Listener methods
of the gui, because it brings the separetly running gui-thread to hang.
Jan

Not needed.


That's the big problem.

One should never extend thread. Instead one should implement Runnable
and feed that to a new thread.




Instead, Sun has a SwingWorker class that does all sorts of nice work in
relation to all this.

Read this section of The Java Tutorial
http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html

The grab the SwingWorker code and use that.

 

[Jon A. Cruz]

Hi all,

I have a background network (in a seperate class) thread running that runs
only once and
waits for a tcp-connection, and finally should return a socket-object of the
connection. I have two
questions: what is the best way to return the socket-object and how can i
signalize or test that the
network-thread is finished with its work? At the moment i try within my
gui-class:

(while thread.isAlive)
{
textfield.setText = "Please wait for connection...";
}
But my textfield isnt updated and my gui-window hangs up too...

That's generally a bad approach.

Instead either fire off a SwingWorker to run the network wait-n-fetch,
or from the network class create a new Runnable() that does the UI
updating calls you want and fire them off using
SwingUtilities.invokeLater().