Nested ManagedBlockers are benign?

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Nested ManagedBlockers are benign?

JSR166 Concurrency mailing list
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?

I ask because I proposed a widely used HTTP client library to wrap blocking network calls transparently for users: https://github.com/square/okhttp/issues/5655, but now I'm not sure it is a good idea if there are some users who already wrap the calls to the library themselves with FJP.managedBlock(), who might then be penalized for their own prudence if nested ManagedBlockers start extra threads.

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Nested ManagedBlockers are benign?

JSR166 Concurrency mailing list
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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Nested ManagedBlockers are benign?

JSR166 Concurrency mailing list
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 <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Nested ManagedBlockers are benign?

JSR166 Concurrency mailing list
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest


--
Cheers,

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