[concurrency-interest] ThreadPoolExecutor workQueue concurrencyissue

Guy Korland gkorland at gmail.com
Tue Dec 11 04:33:46 EST 2007


David,

I didn't defined "some kind of fairness" yet, but I guess that "no more than
X tasks can pass this a task" or "task Y arrived after more than X mills
won't pass another.".

>duplicate the stages to achieve greater parallelism
Seems like a waste to me and might cause from time to time that a task will
wait in the queue even though that the other queue is empty.

Guy Korland

On Dec 11, 2007 11:15 AM, David Holmes <dcholmes at optusnet.com.au> wrote:

>  How do you define "some kind of fairness" ?
>
> When staged/pipelined designs start to saturate like that, you might see
> if you can duplicate the stages to achieve greater parallelism.
>
> David Holmes
>
> -----Original Message-----
> *From:* concurrency-interest-bounces at cs.oswego.edu [mailto:
> concurrency-interest-bounces at cs.oswego.edu]*On Behalf Of *Guy Korland
> *Sent:* Tuesday, 11 December 2007 5:40 PM
> *To:* concurrency-interest at cs.oswego.edu
> *Subject:* [concurrency-interest] ThreadPoolExecutor workQueue
> concurrencyissue
>
> Hi,
> We built an application in a SEDA fashion, working in stages from one
> ThreadPool to another.
> We found out that the BlockingQueue used by the ThreadPoolExecutor became
> a major concurrency killer when we start working on 4 cores machines and
> above.
> The thing is that we don't really need the strong FIFO behavior forced by
> all the BlockingQueue implementations available, some kind of fairness will
> be good enough.
> Any ideas?
>
> Thanks,
> Guy
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20071211/ec4158b3/attachment.html 


More information about the Concurrency-interest mailing list