[concurrency-interest] [Javamemorymodel-discussion] How to interrupt a Thread Pool thread?
davidcholmes at aapt.net.au
Fri Mar 26 19:15:26 EDT 2010
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.
> -----Original Message-----
> From: javamemorymodel-discussion-bounces at cs.umd.edu
> [mailto:javamemorymodel-discussion-bounces at cs.umd.edu]On Behalf Of David
> 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
> 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
More information about the Concurrency-interest