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

From: Michel Lestrade (michel.lestrade_at_[hidden])
Date: 2008-08-24 23:48:36

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" <me22.ca+boost_at_[hidden]>
> Subject: Re: [Boost-users] [Thread] Beginner question regarding thread
> 	groups
> To: boost-users_at_[hidden]
> Message-ID:
> 	<fa28b9250808241856l384711bfw658deaa79ae77d96_at_[hidden]>
> Content-Type: text/plain; charset=UTF-8
>
> On Sun, Aug 24, 2008 at 18:58, Michel Lestrade
> <michel.lestrade_at_[hidden]> 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
>
>
> ------------------------------