[concurrency-interest] Backpressure in ExecutorService with uneven length jobs

Viktor Klang viktor.klang at gmail.com
Tue Oct 3 10:35:37 EDT 2017


Have you considered using ReactiveStreams/j.u.c.Flow?

-- 
Cheers,
√

On Oct 3, 2017 14:55, "Shevek" <shevek at anarres.org> wrote:

> Dear list, I cannot be the first to ask...
>
> In a previous discussion, it was suggested that using CallerRunsPolicy
> with a queue of (say) ncpus * 10 is the canonical way to achieve
> backpressure. However, when the jobs are of particularly uneven sizes,
> sometimes the caller gets a job which runs for so long that all the worker
> threads exhaust the queue and sit idle. I don't have a good bound for the
> unevenness of jobs, and I have a 32-way Xeon.
>
> Is there a good solution to this? Perhaps blocking the caller in submit()
> until space is available in the queue? Would I better write my own queue
> implementation, or wrap the executor in a semaphore?
>
> It's not obviously amenable to an FJP: It's 3 million independent tasks,
> one per node in a graph, although if the answer is "Yes, make an FJP, and
> this is roughly how to make task-stealing do re-balancing", I'll be equally
> happy.
>
> Thank you.
>
> S.
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20171003/e1182aaa/attachment.html>


More information about the Concurrency-interest mailing list