[concurrency-interest] Nested ManagedBlockers are benign?

Doug Lea dl at cs.oswego.edu
Wed Jan 22 07:27:32 EST 2020

On 1/20/20 3:44 PM, Roman Leventov via Concurrency-interest wrote:
> Does calling FJP.managedBlock() within another FJP.managedBlock() call
> usually or always not cause an additional thread to spin up the second
> compensation thread needlessly?

There is nothing built into FJ that remembers if you've called
managedBlock, so if implementations of block() invoke another
ManagedBlocker.block, then FJ may reserve or create multiple worker
threads. Wrapping a large amount of code, most of which does not block,
inside ManagedBlock.block is not recommended. On the other hand, it may
be better than some alternatives in practice.

The ManagedBlocker API was designed for tight wrapping of blocking code.
The reason for "isReleasable" is to reduce false-alarms when blocking is
not necessary: internally, we take snapshot of pool state, then check
isReleasable, then, in effect, compareAndSet state, as a check that
releasability status coincides with state.

And it is a good time for a reminder that when programs rely on
non-blocking sync/IO, less infrastructure of any kind is needed to
obtain acceptable performance, although sometimes at the expense of
other kinds of overhead.


More information about the Concurrency-interest mailing list