Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #22306

Re: nThreads

Show all headers | View raw

On 2/13/13 3:25 PM, bob smith wrote:
> I'm looking at this method in the Executors class:
>
> --------------------------------
> newFixedThreadPool
> public static ExecutorService newFixedThreadPool(int nThreads)
>
> Creates a thread pool that reuses a fixed set of threads operating off a shared unbounded queue. If any thread terminates due to a failure during execution prior to shutdown, a new one will take its place if needed to execute subsequent tasks.
>
> --------------------------------
>
> How much is too much in terms of me telling it how many threads I want?  Is it okay to ask for 100 threads?  What about 256?
>
> Thanks.
>
>
As you have read in the rest of this thread, the answer is "it depends".

You can ask for many many threads (thousands). The real question is "how 
many threads *should* I for task X?"

Which, of course, depends on the task.

A rule of thumb I use for CPU bound tasks (ray-tracing for example) is 
N+1 where N is the number of CPU cores.  The +1 is to have an extra 
thread available to pick up slack if any one of the other threads ends 
up blocked by something, such as synchronization, paging, etc...

For IO bound tasks, I tend not to use a fixed pool, but use a pool that 
automatically adjusts its size to meet demand. You also need to be aware 
of the effect that you might have down-stream.  If your IO is all local 
disk access on a spinning media (eg, non SDD hard disk), too many 
threads *might* cause undue head shifting, slowing down the overall 
operation.

For Memory (or other allocated resource) Intensive tasks, you want to 
have an upper bound of threads that prevents any thread from failing due 
to running out of resources.

For mixed tasks (some tasks which block on IO for a portion of time, 
then process the result in a CPU intensive manor), you'll have to make a 
guess and then fine-tune to each machine.  Provide sensible defaults but 
let the end-user configure it.

As a matter of fact, many applications have configuration options for 
thread-pool size.  Let the end-user (or administrator at least) 
decide/figure out what is best for their particular use-cases, 
workflows, and systems.

HTH,
Daniel.

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

nThreads bob smith <bob@coolfone.comze.com> - 2013-02-13 15:25 -0800
  Re: nThreads Joerg Meier <joergmmeier@arcor.de> - 2013-02-14 00:46 +0100
    Re: nThreads Roedy Green <see_website@mindprod.com.invalid> - 2013-02-14 03:43 -0800
    Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 08:56 -0500
  Re: nThreads markspace <markspace@nospam.nospam> - 2013-02-13 16:06 -0800
    Re: nThreads Joerg Meier <joergmmeier@arcor.de> - 2013-02-14 01:46 +0100
      Re: nThreads Lew <lewbloch@gmail.com> - 2013-02-13 17:27 -0800
      Re: nThreads Robert Klemme <shortcutter@googlemail.com> - 2013-02-14 22:19 +0100
      Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 08:59 -0500
  Re: nThreads Roedy Green <see_website@mindprod.com.invalid> - 2013-02-13 18:37 -0800
    Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 09:01 -0500
  Re: nThreads Arved Sandstrom <asandstrom2@eastlink.ca> - 2013-02-14 07:07 -0400
  Re: nThreads Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2013-02-14 09:55 -0800
  Re: nThreads Arne Vajhoej <arne@vajhoej.dk> - 2013-02-15 08:55 -0500

csiph-web