[concurrency-interest] ThreadPoolExecutor workQueueconcurrencyissue

David Holmes dcholmes at optusnet.com.au
Tue Dec 11 05:04:58 EST 2007


Your "fairness" measure sounds quite involved :)

As for being a waste ... well it all depends on the load. If the pipeline
isn't kept reasonably full it may be a waste. Its your app, and your load.
:) I was simply pointing out another dimension to the solution space.

Cheers,
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 7:34 PM
  To: dholmes at ieee.org
  Cc: concurrency-interest at cs.oswego.edu
  Subject: Re: [concurrency-interest] ThreadPoolExecutor
workQueueconcurrencyissue


  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/25c1c975/attachment-0001.html 


More information about the Concurrency-interest mailing list