[concurrency-interest] Serialized ThreadPoolExecutor

Joe Bowbeer joe.bowbeer at gmail.com
Mon Jul 20 15:14:29 EDT 2009

I'm assuming you've already seen the simple, delegating SerialExecutor
example in the javadoc:


and that you are looking for an efficient way to map a task to its

If the total number of locking keys is manageable, I'd recommend using a
ConcurrentMap and putIfAbsent.  There's a small up-front construction cost,
but SerialExecutor is fairly cheap.  The disadvantage is that map entries
will accumulate, but this may not be a problem.

If the total number of locking keys (hence the number serial executors) is
not manageable then I'm currently at a loss.


On Mon, Jul 20, 2009 at 8:58 AM, Norman Elton wrote:

> I've got a ThreadPoolExecutor that runs tasks. I would like certain
> tasks that implement the LockingJob interface to have a "locking key":
> public interface LockingJob {
>   public Object getLockingKey();
> }
> In this instance, the queue would serialize any jobs sharing a locking
> key. If two jobs come in with key "A", the first must finish executing
> before the second begins. Meanwhile, tasks that do not share that key
> continue to execute as expected.
> I've done this before with a Map<Object,List<Runnable>> that maps a
> locking key to a list of jobs queued up. When a job is added to the
> queue, the executor first checks to see if a "holding queue" exists.
> If so, the job is appended to the list. If not, it is executed
> immediately. When a job is completed, another is popped off the
> holding queue and executed. Problem is, I have to synchronize around
> this holding queue, which seems to introduce a lot of overhead.
> Is there a better way to accomplish what I'm after? Am I completely crazy?
> Thanks,
> Norman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20090720/bf60fc49/attachment.html>

More information about the Concurrency-interest mailing list