<div dir="auto">Have you considered using ReactiveStreams/j.u.c.Flow?<br><br><div data-smartmail="gmail_signature">-- <br>Cheers,<br>√</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 3, 2017 14:55, "Shevek" <<a href="mailto:shevek@anarres.org">shevek@anarres.org</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear list, I cannot be the first to ask...<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
Thank you.<br>
<br>
S.<br>
______________________________<wbr>_________________<br>
Concurrency-interest mailing list<br>
<a href="mailto:Concurrency-interest@cs.oswego.edu" target="_blank">Concurrency-interest@cs.oswego<wbr>.edu</a><br>
<a href="http://cs.oswego.edu/mailman/listinfo/concurrency-interest" rel="noreferrer" target="_blank">http://cs.oswego.edu/mailman/l<wbr>istinfo/concurrency-interest</a><br>
</blockquote></div></div>