Hi everyone,

I want to intitialise an object to perform a certain computation and wait for the object to finish, but I'm not sure what the best way is to go about this.

Here's a couple of methods to give you an idea of what I'd like to do:

private void method()
    if( flag == true )

        if( result == true )

private void activateEngine()
    Engine eng = new Engine();
    result = eng.getResult();

I'm not too savvy with threads yet, so any advice here would be most appreciated.


8 Years
Discussion Span
Last Post by JamesCherrill

The SwingWorker class
is designed to run long tasks in the background and to report back to the caller when finished
"SwingWorker implements java.util.concurrent.Future. This interface allows the background task to provide a return value to the other thread. Other methods in this interface allow cancellation of the background task and discovering whether the background task has finished or been cancelled."
It's probably as easy an intro to Threads as you will find...


The first thing that came to my mind was to pass messages back and forth between the objects. Suppose you have a Cannon, a FireControlOfficer, and a Gunner. The FireControlOfficer wants to just say "Fire when ready", but there's interaction - the gunner can't just say "Cannon, aim yourself", "Cannon, fire yourself" because the cannon takes a finite time to aim itself, and if you fire before it's aimed, you're going to miss the target.

So one way to handle this would be for the gunner, on hearing "fireWhenReady" to set a bit, "fire", to true, and send an "aim" instruction to the cannon. Cannon does its aiming, and sends back a message, "readyToFire". This would be a method which, if fire is set, returns a "goAheadAndShoot" message to the cannon. Lather rinse and repeat until "ceaseFiring" comes down from FireControlOfficer.

You might use a model like this in a GUI that's trying to draw a large data set: you send "update" to the data set, and "drawDataSet" to the GUI. The messages look like they're in sequence, but the GUI gets the instruction to draw while the data set is still trying to calculate itself, and things go pear-shaped. Instead, you let the update method pass a "ready to draw" message off to the GUI, via a method.

Implementing this in your code might help you deal better with the built in material for handling concurrency. You wouldn't want to use home-rolled threading in production code, but just as you want to write your own data structures before you use the library code, it's worth trying to handle concurrency on your own before you just suck up the pre-packaged stuff. You'll end up understanding it better, I think, if you've tried to solve the problems yourself first.
(I don't want to suggest that this is actually how the solutions look in the Threading model implemented in real live Java, of course! This is a total hack, I don't actually know what the real solutions look like)


Thanks for the hints guys!

I've tried a simple approach using a while loop and some boolean flags and I've also had a look at SwingWorker; however the results aren't great yet.

The thing is that I have to wait for 2 threads to finish outside of the Swing event dispatch thread.

I call a class from a GUI-related method (as shown in the above code), and that class initiates a Process (thread 1), which in turn initiates a Receiver class (thread 2) to receive output from the Process.

So, thread 1 has to wait for thread 2 to finish, and the EDT has to wait for thread 1 to finish.

Would SwingWorker still be a good way to tackle this situation?



Do you actually need both the two non-EDT threads, or could you just do all the non-swing stuff on a single thread that processes all the steps serially?

Edited by JamesCherrill: n/a

This topic has been dead for over six months. Start a new discussion instead.
Have something to contribute to this discussion? Please be thoughtful, detailed and courteous, and be sure to adhere to our posting rules.