[concurrency-interest] "Best practice" for ThreadPoolcreation/run-down

David Holmes dcholmes at optusnet.com.au
Tue Jan 8 19:23:33 EST 2008


I'm unclear on what the actual problem is here, is it that as the
application logically completes the idle pool is keeping the VM alive until
all the threads timeout ?

The hardest part of lifecycle management is clearly identifying the end of
the lifecycle. Daemon threads might be the answer, as Endre suggested, as
long as you can ensure that the application won't terminate while the pool
is still processing things.

Providing an explicit shutdown API is the "best practice" - you want people
to have the control they need over these things.

The next issue is whether you can provide a more responsive cleanup for
those people who don't want to clean up after themselves. This becomes
trickier and you typically have no choice but to resort to some kind of
"weak" reference scheme (as described by Gregg) or finalization scheme -
incumbent with all the issues that weak references and finalization bring to
the table. We looked at this in jsr-166 itself, where
Executors.newSingleThreadedExecutor returns an executor instance that has a
finalizer that shuts down the TPE it delegates to. But you have to be very
careful that not having a reference implies the executor is idle (you always
need a wrapper object becuase the threads in the executor keep the executor
strongly referenced) - for example given:

   Future  calculateComplexStuff() {
        Executor e = new ThreadPoolExecutor(...);
        Future result = MyFuture(e, ...);
           // result.get() returns the result and also
           // performs e.shutdown() once the result is
           // available

        // break problem into pieces p
        // for each piece do: e.execute(p);

        return result;

when the reference 'e' is lost the pool is not idle and it would be very
wrong to use a custom TPE that performed shutdown() as a finalization

David Holmes

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Peter
> Kovacs
> Sent: Wednesday, 9 January 2008 12:57 AM
> To: concurrency-interest
> Subject: [concurrency-interest] "Best practice" for
> ThreadPoolcreation/run-down
> Hi,
> I am implementing multi-threaded routines in a Java library to be used
> via Java API. By default, my library "silently" creates the ThreadPool
> it needs. (The library provides API for the user to use whatever
> Executor it wishes to override the default ThreadPool, but the point
> here is the default behavior.) The thing is that the default
> keepAliveTime of the TP is 60 seconds which is (I think) fine. As the
> application is wound down, however, the threads in the pool are
> waiting until their keepAliveTimes expire. That's is fine so far: I
> can provide a handle to shut the TP down without delay at the end of
> the application. But there is this assimmetry which bugs me: I
> silently create something which then needs to be shutdown explicitly
> by the innocent user of the API. Am I the only one to feel
> uncomfortable with this? What is recommended procedure in such cases?
> I've just checked that System.exit(...) doesn't wait for the thread
> pool to wind down. Does this make a difference to my problem? Can I
> rely on the application developer calling System.exit(...)?
> Also, does anyone have it on top their head: how does the existence of
> non-daemon threads affect the termination of an application-context in
> an application container such as Tomcat? (I. e. the case when my
> library is used in a WEB application.)
> Thanks a lot,
> Peter
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at altair.cs.oswego.edu
> http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

More information about the Concurrency-interest mailing list