Re: Nested ManagedBlockers are benign?

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.

-Doug


_______________________________________________
Concurrency-interest mailing list
[email protected]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest