When does ForkJoinPool.commonPool run on the caller thread?

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

When does ForkJoinPool.commonPool run on the caller thread?

JSR166 Concurrency mailing list
Hi,

I can remember reading somewhere that ForkJoinPool can decide to run the task on the caller thread under some circumstances. I probably encountered this effect in form of test hangs on Travis CI (i.e., submitting two tasks to it, one waiting for the other to count down a latch which then never happens). However, when I run code that prints the current thread, I get one of the worker thread names printed, never "main".

The secondary reason I'm asking this is that I've seen benchmarks using ForkJoinPool as the async-provider showing super performance compared to an ExecutorService, often 10x, which is often the difference when I run some code with or without asynchrony. So my guess is that the benchmark has a utilization pattern that makes it run on the caller thread thus not thread-hopping like with an ExecutorService.submit. 


So is there a way to predict if ForkJoinPool will/has run the task on the caller thread?


--
Best regards,
David Karnok

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

Re: When does ForkJoinPool.commonPool run on the caller thread?

JSR166 Concurrency mailing list

Hi David,

 

As far as I can see the only time a submission to a FJP runs on the current thread is if the current thread is a worker thread in that FJP. See FJP.externalSubmit.

 

Cheers,

David H.

 

From: Concurrency-interest <[hidden email]> On Behalf Of Dávid Karnok via Concurrency-interest
Sent: Tuesday, April 3, 2018 7:27 PM
To: concurrency-interest <[hidden email]>
Subject: [concurrency-interest] When does ForkJoinPool.commonPool run on the caller thread?

 

Hi,

 

I can remember reading somewhere that ForkJoinPool can decide to run the task on the caller thread under some circumstances. I probably encountered this effect in form of test hangs on Travis CI (i.e., submitting two tasks to it, one waiting for the other to count down a latch which then never happens). However, when I run code that prints the current thread, I get one of the worker thread names printed, never "main".

 

The secondary reason I'm asking this is that I've seen benchmarks using ForkJoinPool as the async-provider showing super performance compared to an ExecutorService, often 10x, which is often the difference when I run some code with or without asynchrony. So my guess is that the benchmark has a utilization pattern that makes it run on the caller thread thus not thread-hopping like with an ExecutorService.submit. 

 

 

So is there a way to predict if ForkJoinPool will/has run the task on the caller thread?

 

 

--

Best regards,

David Karnok


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

Re: When does ForkJoinPool.commonPool run on the caller thread?

JSR166 Concurrency mailing list
David,

I'd only expect this to occur in FIFO mode. Do you have a link to the version of the source you're referring to?

On Tue, Apr 3, 2018 at 12:07 PM, David Holmes via Concurrency-interest <[hidden email]> wrote:

Hi David,

 

As far as I can see the only time a submission to a FJP runs on the current thread is if the current thread is a worker thread in that FJP. See FJP.externalSubmit.

 

Cheers,

David H.

 

From: Concurrency-interest <[hidden email]> On Behalf Of Dávid Karnok via Concurrency-interest
Sent: Tuesday, April 3, 2018 7:27 PM
To: concurrency-interest <[hidden email]>
Subject: [concurrency-interest] When does ForkJoinPool.commonPool run on the caller thread?

 

Hi,

 

I can remember reading somewhere that ForkJoinPool can decide to run the task on the caller thread under some circumstances. I probably encountered this effect in form of test hangs on Travis CI (i.e., submitting two tasks to it, one waiting for the other to count down a latch which then never happens). However, when I run code that prints the current thread, I get one of the worker thread names printed, never "main".

 

The secondary reason I'm asking this is that I've seen benchmarks using ForkJoinPool as the async-provider showing super performance compared to an ExecutorService, often 10x, which is often the difference when I run some code with or without asynchrony. So my guess is that the benchmark has a utilization pattern that makes it run on the caller thread thus not thread-hopping like with an ExecutorService.submit. 

 

 

So is there a way to predict if ForkJoinPool will/has run the task on the caller thread?

 

 

--

Best regards,

David Karnok


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: When does ForkJoinPool.commonPool run on the caller thread?

JSR166 Concurrency mailing list
Sure:


When I first pushed pushed this, I used `ForkJoinPool.commonPool().submit()` instead of the current `new Thread`. It worked locally but hung on Travis with FJP, not sure why exactly.

Viktor Klang <[hidden email]> ezt írta (időpont: 2018. ápr. 3., K, 17:30):
David,

I'd only expect this to occur in FIFO mode. Do you have a link to the version of the source you're referring to?

On Tue, Apr 3, 2018 at 12:07 PM, David Holmes via Concurrency-interest <[hidden email]> wrote:

Hi David,

 

As far as I can see the only time a submission to a FJP runs on the current thread is if the current thread is a worker thread in that FJP. See FJP.externalSubmit.

 

Cheers,

David H.

 

From: Concurrency-interest <[hidden email]> On Behalf Of Dávid Karnok via Concurrency-interest
Sent: Tuesday, April 3, 2018 7:27 PM
To: concurrency-interest <[hidden email]>
Subject: [concurrency-interest] When does ForkJoinPool.commonPool run on the caller thread?

 

Hi,

 

I can remember reading somewhere that ForkJoinPool can decide to run the task on the caller thread under some circumstances. I probably encountered this effect in form of test hangs on Travis CI (i.e., submitting two tasks to it, one waiting for the other to count down a latch which then never happens). However, when I run code that prints the current thread, I get one of the worker thread names printed, never "main".

 

The secondary reason I'm asking this is that I've seen benchmarks using ForkJoinPool as the async-provider showing super performance compared to an ExecutorService, often 10x, which is often the difference when I run some code with or without asynchrony. So my guess is that the benchmark has a utilization pattern that makes it run on the caller thread thus not thread-hopping like with an ExecutorService.submit. 

 

 

So is there a way to predict if ForkJoinPool will/has run the task on the caller thread?

 

 

--

Best regards,

David Karnok


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




--
Cheers,


--
Best regards,
David Karnok

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

Re: When does ForkJoinPool.commonPool run on the caller thread?

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list
See the internal documentation under Work Queue in FJP:

* WorkQueues are also used in a similar way for tasks submitted
 * to the pool. We cannot mix these tasks in the same queues used
 * by workers. Instead, we randomly associate submission queues
 * with submitting threads, using a form of hashing.  The
 * ThreadLocalRandom probe value serves as a hash code for
 * choosing existing queues, and may be randomly repositioned upon
 * contention with other submitters.  In essence, submitters act
 * like workers except that they are restricted to executing local
 * tasks that they submitted.

ed

On Tue, Apr 3, 2018 at 5:27 AM, Dávid Karnok via Concurrency-interest <[hidden email]> wrote:
Hi,

I can remember reading somewhere that ForkJoinPool can decide to run the task on the caller thread under some circumstances. I probably encountered this effect in form of test hangs on Travis CI (i.e., submitting two tasks to it, one waiting for the other to count down a latch which then never happens). However, when I run code that prints the current thread, I get one of the worker thread names printed, never "main".

The secondary reason I'm asking this is that I've seen benchmarks using ForkJoinPool as the async-provider showing super performance compared to an ExecutorService, often 10x, which is often the difference when I run some code with or without asynchrony. So my guess is that the benchmark has a utilization pattern that makes it run on the caller thread thus not thread-hopping like with an ExecutorService.submit. 


So is there a way to predict if ForkJoinPool will/has run the task on the caller thread?


--
Best regards,
David Karnok

_______________________________________________
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: When does ForkJoinPool.commonPool run on the caller thread?

JSR166 Concurrency mailing list
In reply to this post by JSR166 Concurrency mailing list

It’s just the current JDK sources.

 

http://hg.openjdk.java.net/jdk/jdk/file/a387ee36e5e0/src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java#l1949

 

But I also noted this in the comments:

 

* When external threads submit to the common pool, they can

* perform subtask processing (see externalHelpComplete and

* related methods) upon joins. 

 

Perhaps it is this form of current-thread-runs that David Karnok was thinking of.

 

David H.

 

From: Viktor Klang <[hidden email]>
Sent: Wednesday, April 4, 2018 1:30 AM
To: David Holmes <[hidden email]>
Cc: Dávid Karnok <[hidden email]>; David Holmes <[hidden email]>; concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] When does ForkJoinPool.commonPool run on the caller thread?

 

David,

 

I'd only expect this to occur in FIFO mode. Do you have a link to the version of the source you're referring to?

 

On Tue, Apr 3, 2018 at 12:07 PM, David Holmes via Concurrency-interest <[hidden email]> wrote:

Hi David,

 

As far as I can see the only time a submission to a FJP runs on the current thread is if the current thread is a worker thread in that FJP. See FJP.externalSubmit.

 

Cheers,

David H.

 

From: Concurrency-interest <[hidden email]> On Behalf Of Dávid Karnok via Concurrency-interest
Sent: Tuesday, April 3, 2018 7:27 PM
To: concurrency-interest <[hidden email]>
Subject: [concurrency-interest] When does ForkJoinPool.commonPool run on the caller thread?

 

Hi,

 

I can remember reading somewhere that ForkJoinPool can decide to run the task on the caller thread under some circumstances. I probably encountered this effect in form of test hangs on Travis CI (i.e., submitting two tasks to it, one waiting for the other to count down a latch which then never happens). However, when I run code that prints the current thread, I get one of the worker thread names printed, never "main".

 

The secondary reason I'm asking this is that I've seen benchmarks using ForkJoinPool as the async-provider showing super performance compared to an ExecutorService, often 10x, which is often the difference when I run some code with or without asynchrony. So my guess is that the benchmark has a utilization pattern that makes it run on the caller thread thus not thread-hopping like with an ExecutorService.submit. 

 

 

So is there a way to predict if ForkJoinPool will/has run the task on the caller thread?

 

 

--

Best regards,

David Karnok


_______________________________________________
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
Reply | Threaded
Open this post in threaded view
|

Re: When does ForkJoinPool.commonPool run on the caller thread?

JSR166 Concurrency mailing list
To add an example that uses the submitting thread as a worker, from some time ago:

public static void main(final String[] a) {
    Stream.of(1, 2, 3, 4, 5, 6, 7, 8).map(i -> ForkJoinPool.commonPool().submit(new RecursiveAction() {
        protected void compute() {
            System.out.println(Thread.currentThread());
        }
    })).forEach(ForkJoinTask::join);
}

ed

On Tue, Apr 3, 2018 at 5:00 PM, David Holmes via Concurrency-interest <[hidden email]> wrote:

It’s just the current JDK sources.

 

http://hg.openjdk.java.net/jdk/jdk/file/a387ee36e5e0/src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java#l1949

 

But I also noted this in the comments:

 

* When external threads submit to the common pool, they can

* perform subtask processing (see externalHelpComplete and

* related methods) upon joins. 

 

Perhaps it is this form of current-thread-runs that David Karnok was thinking of.

 

David H.

 

From: Viktor Klang <[hidden email]>
Sent: Wednesday, April 4, 2018 1:30 AM
To: David Holmes <[hidden email]>
Cc: Dávid Karnok <[hidden email]>; David Holmes <[hidden email]>; concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] When does ForkJoinPool.commonPool run on the caller thread?

 

David,

 

I'd only expect this to occur in FIFO mode. Do you have a link to the version of the source you're referring to?

 

On Tue, Apr 3, 2018 at 12:07 PM, David Holmes via Concurrency-interest <[hidden email]> wrote:

Hi David,

 

As far as I can see the only time a submission to a FJP runs on the current thread is if the current thread is a worker thread in that FJP. See FJP.externalSubmit.

 

Cheers,

David H.

 

From: Concurrency-interest <[hidden email]> On Behalf Of Dávid Karnok via Concurrency-interest
Sent: Tuesday, April 3, 2018 7:27 PM
To: concurrency-interest <[hidden email]>
Subject: [concurrency-interest] When does ForkJoinPool.commonPool run on the caller thread?

 

Hi,

 

I can remember reading somewhere that ForkJoinPool can decide to run the task on the caller thread under some circumstances. I probably encountered this effect in form of test hangs on Travis CI (i.e., submitting two tasks to it, one waiting for the other to count down a latch which then never happens). However, when I run code that prints the current thread, I get one of the worker thread names printed, never "main".

 

The secondary reason I'm asking this is that I've seen benchmarks using ForkJoinPool as the async-provider showing super performance compared to an ExecutorService, often 10x, which is often the difference when I run some code with or without asynchrony. So my guess is that the benchmark has a utilization pattern that makes it run on the caller thread thus not thread-hopping like with an ExecutorService.submit. 

 

 

So is there a way to predict if ForkJoinPool will/has run the task on the caller thread?

 

 

--

Best regards,

David Karnok


_______________________________________________
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



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