open up ForkJoinPool.managedBlock to other pool implementations

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

open up ForkJoinPool.managedBlock to other pool implementations

JSR166 Concurrency mailing list
With the updates being made to the ForkJoinPool and the wider adoption of ManagedBlocker across the j.u.c blocking classes I'm curious if there would be interest/willingness to open this up for use by other thread pool implementations.  Specifically ForkJoinPool.managedBlock currently only supports notifying ForkJoinWorkerThreads that they will be block, but it. would seem fairly trivial to support this more generically.  For instance there could be a BlockingAware interface which ForkJoinWorkerThread would implement:

interface BlockingAware {
    void managedBlock(ManagedBlocker blocker)
        throws InterruptedException;
}

And then ForkJoinPool.managedBlock could just be:

public static void managedBlock(ManagedBlocker blocker)
    throws InterruptedException {
    Thread t = Thread.currentThread();
    if (t instanceof BlockingAware)
        ((BlockingAware) t).managedBlock(blocker);
    else
        unmanagedBlock(blocker);
}

With ForkJoinWorkerThread's managedBlock implementation being:

void managedBlock(ManagedBlocker blocker) {
    if (pool == null) {
        ForkJoinPool.unmanagedBlock(blocker);
    }
    else {
        ForkJoinPool.compensateBlock(blocker);
    }
}

This would then allow other thread pool implementations to implement BlockingAware and to be notified when their threads block on a ManagedBlocker.  

I suppose taking things a bit further ManagedBlocker should exist at j.u.c with FJP.ManagedBlocker extending that, and similarly the FJP.managedBlock static method would ideally also be exposed on class other then FJP, perhaps as a static method on ManagedBlocker itself.

thanks,

Mark

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

Re: open up ForkJoinPool.managedBlock to other pool implementations

JSR166 Concurrency mailing list
On 1/22/20 8:34 AM, Mark Falco via Concurrency-interest wrote:
> With the updates being made to the ForkJoinPool and the wider adoption
> of ManagedBlocker across the j.u.c blocking classes I'm curious if there
> would be interest/willingness to open this up for use by other thread
> pool implementations. 

I had considered this, but it's not clear how useful it would be.  For
ThreadPoolExecutors (TPE, the basis of most Executors class factories)
the action would need to conform to the other tunable settings (core
threads etc), which invites unexpected problems. The least problematic
cases are TPEs corresponding to Executors.newFixedThreadPool(n). But
here, it's usually better to replace these pools with "new
ForkJoinPool(n)". At one point, we considered replacing the Executors
factory method to do this. But noticed that are a couple of corner-case
incompatibilities across TPE and FJP involving interactions of timeouts
and interrupts. These are not commonly encountered, but we have a lot of
tests for them, so we know them well. I'll re-investigate whether these
differences can be removed. If so, we might reconsider redefining
newFixedThreadPool, or at least adding a usage note that people should
consider FJP as an alternative.

-Doug




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

Re: open up ForkJoinPool.managedBlock to other pool implementations

JSR166 Concurrency mailing list
I wasn’t so much thing about their potential use in TPE, but in non-JDK pools. The ability to know that your thread is blocked is such a critically useful piece of information and I’d love to have access to it for my own custom pool implementations and I imagine other may as well.

thanks again,

Mark

> On Jan 22, 2020, at 7:12 PM, Doug Lea via Concurrency-interest <[hidden email]> wrote:
>
> On 1/22/20 8:34 AM, Mark Falco via Concurrency-interest wrote:
>> With the updates being made to the ForkJoinPool and the wider adoption
>> of ManagedBlocker across the j.u.c blocking classes I'm curious if there
>> would be interest/willingness to open this up for use by other thread
>> pool implementations.  
>
> I had considered this, but it's not clear how useful it would be.  For
> ThreadPoolExecutors (TPE, the basis of most Executors class factories)
> the action would need to conform to the other tunable settings (core
> threads etc), which invites unexpected problems. The least problematic
> cases are TPEs corresponding to Executors.newFixedThreadPool(n). But
> here, it's usually better to replace these pools with "new
> ForkJoinPool(n)". At one point, we considered replacing the Executors
> factory method to do this. But noticed that are a couple of corner-case
> incompatibilities across TPE and FJP involving interactions of timeouts
> and interrupts. These are not commonly encountered, but we have a lot of
> tests for them, so we know them well. I'll re-investigate whether these
> differences can be removed. If so, we might reconsider redefining
> newFixedThreadPool, or at least adding a usage note that people should
> consider FJP as an alternative.
>
> -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