[concurrency-interest] ThreadPoolExecutor.terminated()

Jeff Hain jeffhain at rocketmail.com
Fri Aug 3 09:59:18 EDT 2012


Hello.
At some point in history, ThreadPoolExecutor.terminated()
was not invoked from within main lock, and was invoked
_after_ state setting to TERMINATED (as its Javadoc still
seems to state):

            mainLock.lock();
            try {
                (...)
            } finally {
                mainLock.unlock();
            }
            if (fullyTerminated)
                terminated();

Now, it's called from within main lock, and before
state update:

            mainLock.lock();
            try {
                if (ctl.compareAndSet(c, ctlOf(TIDYING, 0))) {
                    try {
                        terminated();
                    } finally {
                        ctl.set(ctlOf(TERMINATED, 0));
                        termination.signalAll();
                    }
                    return;
                }
            } finally {
                mainLock.unlock();
            }

I can see a reason for calling terminated() before state change,
i.e. that whoever reads TERMINATED knows that terminated()
has been called.

Though, terminated() being called in main lock could cause deadlocks,
and I don't see a reason for it (other than making sure that _only_
whoever is in terminated() can see TIDYING state when holding lock,
but why would it be useful?).

Can please anyone enlighten me about it?

-Jeff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20120803/51578ac6/attachment.html>


More information about the Concurrency-interest mailing list