[concurrency-interest] Nested ManagedBlockers are benign?

Roman Leventov 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
in ForkJoinWorkerThread.

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.
>
> -Doug
>
>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20200122/de549a9c/attachment.htm>


More information about the Concurrency-interest mailing list