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

------------------------------