[concurrency-interest] [Javamemorymodel-discussion] How to interrupt a Thread Pool thread?

David Holmes davidcholmes at aapt.net.au
Fri Mar 26 19:15:26 EDT 2010

Hi David,

I've redirected this to the concurrency-interest list.

One of the easiest ways to interrupt threads in a pool is to use the
interrupt() method on the ThreadGroup. But in short there are a number of
ways to get a hold of a Thread reference for a pool thread, most of which
you should not do, but there's nothing to stop you. And things you might
have done in a legacy design should not necessarily be carried over when
using an Executor.

By very strange coincidence I came across your guidelines just yesterday.

David Holmes

> -----Original Message-----
> From: javamemorymodel-discussion-bounces at cs.umd.edu
> [mailto:javamemorymodel-discussion-bounces at cs.umd.edu]On Behalf Of David
> Svoboda
> Sent: Saturday, 27 March 2010 12:39 AM
> To: javamemorymodel-discussion at cs.umd.edu
> Cc: David Svoboda
> Subject: [Javamemorymodel-discussion] How to interrupt a Thread Pool
> thread?
> While working on our Java Secure Coding standard rule CON35-J, we came
> across this excerpt from _Java Concurrency in Practice_, by Brian
> Goetz, Tim Peierls, Joshua Bloch, Joseph Bowbeer, David Holmes, Doug
> Lea. Addison Wesley Professional. (2006), pg 146:
>       You should note interrupt a pool thread directly when attempting to
>       cancel a task, because you won't know which task is running when
>       the interrupt request is delivered--do this only through the
>       task's Future.
> However, when studying the APIs supplied by J2SE for managing thread
> pools, such as ExecutorService, we discovered that they don't actually
> provide any API to access a Thread object that is part of a pool. So
> Java does not make it easy to interrupt a pool thread. I can think of
> only two ways to do it:
> (1) Have a pool thread stash its Thread.currentThread() property
>      somewhere that outside threads can access
> (2) Build your own thread pool that provides public access to the
>      threads in its pool
> Both seem quite complicated and intricate and not the type of mistake
> people are likely to make. Furthermore, if you go to the effort of
> building your own thread pool with publicly-accessible, you can also
> go to the effort of providing enough safety to interrupt your thread
> pool threads from outside the pool.
> So our question is, what did Goetz et al. mean by this statement? Is it
> a purely theoretical exercise and not likely to actually happen? Or is
> there some use case we haven't considered?
> CON35-J link: https://www.securecoding.cert.org/confluence/x/wICGAg
> --
> David Svoboda <svoboda at cert.org>
> Software Security Engineer
> CERT Secure Coding
> (412) 268-3965
> _______________________________________________
> Javamemorymodel-discussion mailing list
> Javamemorymodel-discussion at cs.umd.edu
> https://mailman.cs.umd.edu/mailman/listinfo/javamemorymodel-discussion

More information about the Concurrency-interest mailing list