[concurrency-interest] Adding ForkJoinPool.setPoolSizeLimit

√iktor Ҡlang viktor.klang at gmail.com
Thu Jan 12 15:45:26 EST 2012


2012/1/12 Doug Lea <dl at cs.oswego.edu>

> As I was just reminded, one benefit of FJP currently
> NOT having dynamic configuration methods is that
> different parts of a system all using the same FJP
> cannot hurt each others usages by changing settings
> in a way that only work well for one part. This
> benefit seems worth preserving.
>
> Which makes an alternative (once suggested by Viktor
> and others) that doesn't expose control more attractive:
>

Yeah, this is very nice.


>
> There already is a way to limit pool size: Use a
> ForkJoinPool.**ForkJoinWorkerThreadFactory that returns
> null when it doesn't want to create additional
> threads due to resource constraints. FJP copes
> with null returns from ForkJoinWorkerThreadFactory.**newThread,
> and does so reasonably cheaply (which can/will be
> made a bit cheaper still). Because the pool
> is provided as an argument to newThread, the
> factory can check the current size and state when
> doing so.
>

Excellent tip.


>
> For management and monitoring purposes this option
> would be nicer if ForkJoinWorkerThreadFactory had
> a second method
>  void terminated(**ForkJoinWorkerThread w)
> that is invoked when a worker thread is terminated.
>

Sounds like Pool-style behavior, cool.


> Only full termination seems possible -- we cannot reuse
> these threads unless we change specs about
> UncaughtExceptionHandlers, etc.
> And anyway, creation/termination cycles tend to be long
> enough in FJ that the extra bookkeeping necessary to reuse vs
> recreate would rarely pay for itself.
>
> Because ForkJoinWorkerThreadFactory is a nested
> interface, doing this would be reasonably straightforward.
> We could define:
>
> public static interface ManagedForkJoinWorkerThreadFac**tory
>  extends ForkJoinWorkerThreadFactory {
>  void terminated(**ForkJoinWorkerThread w);
> }
>
> And then add a few instanceof checks internally
> to invoke terminated() if the provided factory
> supports it.
>
> If we take this option, then we should further consider
> any other methods to add to this subinterface while we are
> at it. Suggestions welcome.
>
> Note though that even without a termination callback,
> the existing mechanics above can minimally suffice (although
> in a messier way), because of the opportunity for status probes
> inside method newThread -- the main limitation is that these
> queries can tell you only how many threads there are, but not
> which threads are still alive.
>
> Some replies:
>
>
>
> On 01/12/12 09:57, √iktor Ҡlang wrote:
>
>  1) Should there be any possible backpressure for the FJP?
>>
>
> Do you have something in mind beyond the things I mentioned above?


Nevermind, I've already come up with a way to solve this on a higher level
:-)


>
>
>  2) What's the current behavior for submissions during shutdown?
>>
>
> The same as ThreadPoolExecutor. Upon shutdown, no new
> submissions are accepted but existing tasks are processed
> until the pool is quiescent, at which point it terminates.


We're talking RejectedExecutionException? If so, then that's completely
fine with me.

Cheers,
√


>
> -Doug
>
>
>


-- 
Viktor Klang

Akka Tech Lead
Typesafe <http://www.typesafe.com/> - The software stack for applications
that scale

Twitter: @viktorklang
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120112/eec21a69/attachment.html>


More information about the Concurrency-interest mailing list