views:

80

answers:

3

I want to create a background Thread handling some tasks (Runnable) and executing them in the order in which they are posted.

Important : these tasks must NOT be executed on the Event Dispatcher Thread.

Something like :

BackgroundEventThread backgroundEventThread  = new BackgroundEventThread();

then, later, and in many places in the code:

Runnable thingToDo = new Runnable(){...};

backgroundEventThread.executeThis(thingToDo);
//the things to do will be executed in the order in which they are posted.

The class BackgroundEventThread should be quite straightforward to code, but I was wondering if such a class already existed in some place unknown to me in the JDK or in some common library...

EDIT : I don't know in advance the number of tasks to execute on this thread.

I could have:

  • task0 (really short) happening at t0
  • task1 (long to process...) happening at t0+1s
  • task2 (short) happening at t0+5s etc.
  • task3 (etc, etc...)

And I need task2 (that I don't know in advance) to be executed after task1, and I want all these tasks to be executed asap.

Exactly like tasks posted on the EDT, but NOT on the EDT.

+2  A: 

Check SwingWorker

An abstract class to perform lengthy GUI-interacting tasks in a dedicated thread.

All the necessary details as of how to use it are in the javadoc.

Bozho
Does `SwingWorker` guarantee execution order?
Matthew Murdoch
It is not exactly what I'm looking for:- I don't need any interaction with the EDT- My tasks are short, and there are many of them, that can be created any time. So I would need many swing workers, and I cant be sure that all of them will share the same background thread.
Laurent K
it's asynchronous, hence no execution order (if I get your question correctly). If you want two subsequent operations in the background, use one swing worker with two helper classes which execute each of the sequential tasks.Additionally, I think you can control the number of async threads via ThreadPoolExecutor
Bozho
Why do you need them to share the same background thread?
Bozho
I see a contradiction with this requirement: "Important : these tasks must NOT be executed on the Event Dispatcher Thread."
Carl Smotricz
Carl, what do you mean? a contradiction between SwingWorker and the requirement, or a contradiction withing the requirement itself?
Bozho
@Carl Smotricz : Because on the swing EventDispatcherThread they would freeze the GUI. And these are background tasks.
Laurent K
@Bozho : see my edit, and thank you for your interest
Laurent K
@Carl, SwingWorker uses ThreadPoolExecutor internally to do the job, so I don't see a contradiction.
Bozho
From SwingWorker's doc, it's apparently used "to perform lengthy GUI-interacting tasks in a dedicated task". But there's no requirement for GUI interaction, and specifically a requirement not to run this stuff on the EDT.
Carl Smotricz
and the docs are clear that the EDT is only notified, not used..
Bozho
Yep, I see that. But if there's no requirement for notifying the EDT, why bother using the specialized class?
Carl Smotricz
Yes, for a simple task it might be oversized. But it is not contradicting the requirement.I'd still use SwingWorker in this situation, because in the future I might need the additional functionality.
Bozho
+3  A: 

Sounds like a job for java.util.concurrent.ThreadPoolExecutor.

You can set this up with a "pool" of a single thread, and then throw tasks at it to execute for you.

Carl Smotricz
btw, SwingWorker uses exactly ThreadPoolExecutor internally. Only it has a constant defining the max threads.
Bozho
+2  A: 

It should be possible to configure an ExecutorService to do exactly what you need.

Bombe