[concurrency-interest] Queue.add() vs Executor.exec()

Gregg Wonderly gregg at cytetech.com
Sat Jan 20 17:00:21 EST 2007

Martin Buchholz wrote:
>From: Gregg Wonderly <gregg at cytetech.com>
>>It seems that if the core thread pool size is non-zero that the associated 
>>number of threads would be running and prepared to take whatever was put onto 
>>the queue.
> The number of threads might be zero even if core pool size is non-zero.
> Did you call prestartAllCoreThreads() ?

No, I didn't do that.  I generally seem to code the use of these things 
correctly, and am able to type "executor.exec" correctly.  It's just those times 
when I don't which have caused me to ask this question.  The fact that Queue and 
ThreadPoolExecutor work together causes be to think about this a little harder. 
  It seems counter intuitive that you can't talk to the Queue directly.  As an 
example, imagine an API which passes around a Queue for code to add elements 
too.  You don't want to expose the TPE because that allows users to stop it, 
peek into it and otherwise futz with things that you might not intend them to 
have access to.  The Queue, while allowing certain types of modifications, is a 
different beast.  I guess, in the end, creating a wrapper object to hide them 
both and expose the minimal API would work fine.

I'm just trying to get some thoughts from others on whether this issue seems 
important.  The more I think about it, the more I think that these two objects 
don't work together quite as well as they could/should.

It seems that prestartAllCoreThreads() should be the default with a constructor 
that could say otherwise.

> In general, adding directly to the queue is asking for trouble.
> I dream of writing my own thread pool where the queue would not be
> user-accessible.

Adding to the queue, somehow floats into by typing patterns from using queues 
and other collections in other places so frequently.  So, occasionally, I seem 
to be good at typing queue.add instead of exec.execute, and that's the issue 
that I'm trying to bring to light.  The software fails to work, and it takes 
considerable investigation in some cases to see that the wrong object is being 
used in that way.

> A number of issues with TPE/STPE are being worked on for jdk7,
> including some that leave the pool with less than the
> desired number of threads.

It will be great to get these issues addressed.  I'm just wondering if there 
shouldn't be some investigation and thought into a mechanism which could keep 
one from manipulating (in terms of mutations) the queue object once the TPE is 
using it.

In particular, I'm thinking about something like a 
CollectionModificationListener that might be a more general concept usable in 
other cases that could be used by the TPE to know that the user is adding 
objects directly, and either throw an exception, or allow it to happen taking 
the appropriate actions.

Gregg Wonderly

More information about the Concurrency-interest mailing list