Re: [Boost-users] [Thread] Beginner question regarding thread

25 Aug 2008

      Hi,

So if I understand your suggestion, I should create a container holding 
rays yet to be processed and then run a while loop until this 
queue/container is empty. Within that loop, I create a smaller number of 
threads by popping rays from the queue and let the threads run until 
they finish before going on to the next iteration.

Did I understand you correctly ?  It's a good idea and, from the little 
I know on the subject, it sounds a lot like a "thread pool".

Guess I misunderstood the concept behind thread_group since I thought it 
was doing that already ... There's even a hardware_concurrency() 
function to determine the number of cores/cpus which I thought was 
intended to control how many threads were to be running at once.

Regards,

Michel Lestrade
Crosslight Software
...
------------------------------
Message: 7
Date: Sun, 24 Aug 2008 21:56:49 -0400
From: "Scott McMurray" 
Subject: Re: [Boost-users] [Thread] Beginner question regarding thread
  groups
To: boost-users@lists.boost.org
Message-ID:

Content-Type: text/plain; charset=UTF-8
On Sun, Aug 24, 2008 at 18:58, Michel Lestrade
 wrote:
...
...
I am considering rewriting part of our ray tracing code to use the Boost
thread library. As many of you might know, ray tracing is a task that lends
itself well to a parallel approach since each ray is independent from the
other. However, the code right now is in Fortran which doesn't support task
level parallelism easily ... The thread_group class seems ideally suited to
my needs (one thread == one ray) but there is at least one problem I
envision that I would like to solve before embarking on this fairly
time-consuming rewrite.
It's worth pointing out that, as I recall, you don't really want more
continually-active threads than, say, twice your number of cores.  It
would be nice to run one thread per ray, but the switching and OS
management overhead will kill you if you attempt to run thousands of
threads at once, which I assume you'd need with 1:1.  (Erlang, for
example, which is conceptually based on many, many communicating
processes, uses its own implementation, rather than OS threads of
processes.)
I think you'd be much better off creating a "ray queue" of some sort,
then using a thread_group with cores+1 threads that all continually
poll the ray queue for which one to work on.
So that's not exactly an answer to the question you asked, but I think
that's the usual wisdom with regards to threads.
HTH,
~ Scott
------------------------------