[concurrency-interest] Target CPU utilization

Peter Kovacs peter.kovacs.1.0rc at gmail.com
Fri Feb 16 12:28:57 EST 2007


Thank you, Greg, for your input!

What if an Executor is not sufficient and I need at least an
ExecutorService? The edu.emory.mathcs.backport.java.util.concurrent
does not seem to provide an obvious way to wrapping up an Executor
instance into an ExecutorService.

Similiarily to the way the static methods of the Executors class wrap
up ThreadFactory instances  into Executor instances
(http://dcl.mathcs.emory.edu/util/backport-util-concurrent/doc/api/edu/emory/mathcs/backport/java/util/concurrent/Executors.html),
I would expect an ExecutorServices to be there for wrapping up
Executor instances into ExecutorService instances. Does this make
sense or is there a good reason for the lack of this kind of
functionality?

Thanks
Peter

On 2/16/07,  Gregg Wonderly <gergg at cox.net> wrote:
>  Brian Goetz wrote:
> > All this said, usually U=1.  And, realistically, setting three pool
> > sizes does not have to be that exact, as long as you avoid the extremes
> > of "way too small" and "way too big".
> >
> > That said, if you have a library which will be managing threads, you
> > need to present it to the application as a service, with lifecycle
> > methods like shutdown().  Otherwise, your user's applications will not
> > be able to shut down.  And, if you have a lifecycle interface, that
> > gives you room to let the user supply (optionally) an Executor to be
> > used to process tasks.
>
> I like having the ability to plug all aspects of thread pooling.  Having a
> default implementation that works fine for J2SE would be nice.  Then, you could
> provide for plugging a thread factory and as Brian says, even an executor so
> that while your library partitions the work, the application could still decide
> on the relative priority and queuing necessary to use it effectively.
>
> Gregg Wonderly
>


More information about the Concurrency-interest mailing list