Re: Nested ManagedBlockers are benign?

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 <
[email protected]> 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
> [email protected]
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>

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