[concurrency-interest] Nested ManagedBlockers are benign?

Viktor Klang viktor.klang at gmail.com
Wed Jan 22 11:20:21 EST 2020


Yes, it would seem to be possible to have a local flag in the FJWT which is
set to on before the call to block() and then is set to off after it.

On Wed, Jan 22, 2020 at 4:04 PM Roman Leventov via Concurrency-interest <
concurrency-interest at cs.oswego.edu> wrote:

> 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
>>
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>


-- 
Cheers,
√
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20200122/76a4364b/attachment.htm>


More information about the Concurrency-interest mailing list