views:

179

answers:

4

Experts -

I need some advice in the following scenario.

I have a configuration file with a list of tasks. Each task can have zero, one or more dependencies. I wanted to execute these tasks in parallel [right now they are being executed sequentially]

The idea is to have a main program to read the configuration file and load all the tasks. Read individual tasks and give it to an executor [callable] that will perform the task and return results in a Future. When the task is submitted to the executor (thread) it will monitor for its dependencies to finish first and perform its own task.

Is this the right approach? Are there any other better approaches using java 1.5 features?

+3  A: 

What you have described is the Java5/6 approach.

Just make sure that your tasks/Callables are threadsafe / don't share state.

matt b
+5  A: 

Sounds fine, but beware of Thread starvation deadlock. Basically, don't use a bounded thread pool.

Here is a example that illustrates this problem.
http://www.javaconcurrencyinpractice.com/listings/ThreadDeadlock.java

Also, if you have e.g. a pooled DB connection, you might run into problem, too. 10 threads can block, holding all the pooled connection, waiting for the 11th thread that can't acquire the 11th pooled connection because there isn't anymore available..

Enno Shioji
+1. This kind of question is common on SO and someone always suggests the "submit all tasks at once" solution without mentioning this risk.
finnw
I think the other lession from ThreadDeadlock.java is "be careful with tasks submitting more tasks". In some environments, you want to set a max bound on the thread pool.
matt b
I guess, I started running into problem. How can I resolve it ?
HonorGod
@HonorGod: Um, you need to show us code/describe the problem you are facing.. I suggest you open a new question.
Enno Shioji
+1  A: 

Consider using ValueFuture (from guava) to communicate between tasks. Add a listener to each ValueFuture which submits a new task to the ExecutorService only when all of its inputs are available. That way you will never have a thread block part-way through a task waiting for another task to finish.

finnw
Heh, that seems to be a great idea! +1
Enno Shioji
+1  A: 

Database activity, archiving and rule processing are perfect uses for Ant (or even Maven)

Don't reinvent this. Just use Ant.

Write Ant Tasks for each task. Define the dependencies in XML, using Ant's dependency rules.

Turn Ant loose to run your tasks based on the dependencies. You can start out with "executable" Ant Tasks (http://ant.apache.org/manual/tasksoverview.html#exec) rather than defining your own subclass of Task.

Ant understands parallel tasks. You don't need to do anything but declare the tasks as parallel. http://ant.apache.org/manual/CoreTasks/parallel.html

Don't invent any new software for this. Use Ant.

S.Lott
Can you embed ant in a java application?
Enno Shioji
@Zwei Steinen: Ant already is a Java application. Why would you "embed" it in anything?
S.Lott
I only knew it as a build tool.. I took a look at the manual though. So presumably you can add ant.jar as a dependency to your project, and programmatically call ant scripts that describe the tasks?
Enno Shioji
That's the point of ant -- resolve dependencies by executing tasks. That's it's only point. Compiling and creating a JAR file is the most common application of that kind of processing. But *anything* that involves processing and dependencies can be handled elegantly by Ant.
S.Lott
I know the very general usage of ANT...building by resolving dependencies[which I use most frequently]! My I am specifically asking for multi-threading....does ANT support this as well?
HonorGod
You don't want multi-threading. You want multiple external tasks, as described here: http://ant.apache.org/manual/CoreTasks/parallel.html. Multiple threads are ONLY appropriate when your problem involves a lot of shared state. Your description of independent tasks does not mention shared state; multiple threads will not be of any benefit. Use multiple external processes and things will be (a) fast and (b) simple.
S.Lott