[concurrency-interest] Nested ManagedBlockers are benign?
leventov.ru at gmail.com
Wed Jan 22 11:01:43 EST 2020
Thanks for the clarification.
Do you think it makes sense to prevent nested ManagedBlockers from creating
many workers? Seems to me it might be done with a single flag
On Wed, 22 Jan 2020 at 14:29, Doug Lea via Concurrency-interest <
concurrency-interest at cs.oswego.edu> wrote:
> 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.
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Concurrency-interest