Skip to main content

[Concurrency] Seeking advice on practical use of Executors

2 replies [Last post]
Joined: 2008-04-06

I'm writing a financial application which deal with stock market data and a large number of other 'events.'

Inspired by "Flexible Event Delivery with Executors" ( I've written a small event dispatching framework.

I use Executors quite a bit in this framework. Each event type has a thread pool executor associated with it. Four my 4 cpu machine, I end up with 7 or 8 thread pools, each pool containing 2 to 4 threads.

This doesn't look right to me. Should I define a global Executor thread pool with threads equal to some multiple of the number of CPUs, and pass in this global pool to each event dispatcher....or should I create a new pool for each dispatcher?

--Below I describe my framework in simple terms--
A class can subscribe to events through the following interface:

public interface IEventConsumer {
void onMessage(E e);

A class can advertise that it provides events through the following interface:

public interface IEventDispatcher {
EventDispatcher getDispatcher();

For example:
IEventDispatcher currentTime = new CurrentTime();
currentTime.getDispatcher.addListener(new IEventConsumer(){

onMessage(Time time){
System.out.println("The current time is "+ time.toString());

Inside CurrentTime class, the logic executes the following line every second:
class CurrentTime ... {
EventDispatcher dispatcher = new ... //<==This is the important class
//every one second
dispatcher.dispatch(the current time);

The EventDispatcher class is the one that contains the thread pool:
constructor{ ExecutorService executor = new thread pool}
dispatch(E e){
for each listener{
executor.execute(new Runnable(){ listener.onMessage(e) } );


I hope that made sense. Each event in my application (bids, offers, last sale prices, new orders, cancels, rejects, etc.) have a separate dispatcher associated with them. Should they each have their own thread pool or should they share one larger pool?

Any other comments about the framework?

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2006-12-18

On the topic of creating several distinct executors or using a single one, that depends on the nature of your events and how your applications handle them. In essence, this question boils down to whether you want to pool your event handling or not.

Pooling gives you greater flexibility in dealing with event bursts; whether there are twenty TimeEvents or thirteen StockEvents and seven CancelEvents doesn't matter to a 'pooled' executor. But if you have large bursts of, say, TimeEvents, you may inadvertedly starve other event buckets.

By using separate executors, you 'reserve' threads to deal with specific kinds of events, preventing starvation but also leaving potential optimalisation. Threads reserved to TimeEvents aren't going to help out with StockEvents, no matter how swamped the latter is.

Since you have a framework to hide the complexity, you can make a hybrid of both solutions: have each type of event or handler have its own (small) executor, and use a larger, pooled executor that they can use for 'excessive' events, to deal with bursts or unexpected long computations. Basically, use your own pool if possible, and borrow from the big pool when necessary. In this way, you guarantee that events of any type [i]will[/i] be processed no matter how hostile the environment, and you can deal with bursts of spurious nature.

I've not done this myself, so I can't comment on the actual implementation --it's possible you're even best off writing your own Executor implementation-- but this is likely to give you a kind of golden middle road where you have both guarantees and flexibility.

Hope this helps,

Joined: 2008-04-06

Thanks Jonathan ,
I think the best approach is for me to simply try out the two strategies, run performance numbers and see which one my app needs.