[concurrency-interest] Queue.add() vs Executor.exec()
dcholmes at optusnet.com.au
Wed Feb 7 02:34:46 EST 2007
Sorry for the late reply but I was on vacation and am still catching up.
To be able to use the queue directly and have it "just work" either the
queue needs to know about the pool, or else the pool must always have
threads ready to read from the queue. Having the queue know about the pool
means the queue is no longer just a BlockingQueue. Have the pool always
ready to read from the queue means you don't have control of the number of
threads that you generally would want (you could add heuristics to examine
the length of the queue after take() returns and use that to add more
threads etc - but that's messy).
Just my 2c.
> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Gregg
> Sent: Sunday, 21 January 2007 8:00 AM
> To: Martin Buchholz
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Queue.add() vs Executor.exec()
> Martin Buchholz wrote:
> >From: Gregg Wonderly <gregg at cytetech.com>
> >>It seems that if the core thread pool size is non-zero that the
> >>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
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
More information about the Concurrency-interest