Re: [boost] Boost.Threads, N2178, N2184, et al

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-03-28 18:08:58

A few days late, but...

Peter Dimov wrote:
> Yuval Ronen wrote:
> 
>> One overhead I can think of is the need to call CloseHandle after the
>> WaitForSingleObject, which means another OS call (kernel?). This
>> doesn't exist on pthreads where calling pthread_join is enough.
> 
> The overhead in this case is not measured in cycles or kernel transitions 
> (remember that you called a blocking function because you have nothing 
> better to do with the CPU).

The kernel transitions take CPU cycles, which means these cycles won't 
be available to any thread, not just the one that joined. AFAIU, all 
threads in all process would suffer from this overhead, because CPU 
cycles were wasted. On the other hand, one might say that if the total 
cost of creating + destroying a thread is much more than a single kernel 
transition (is it?), then adding one such transition is negligible.

> It's measured in kernel objects; these come from 
> the nonpaged pool and are a (relatively) limited resource. Since (today) a 
> cv under Windows is usually ~3 kernel objects, a mutex one more, adding a 
> mutex+cv to every thread increases its kernel footprint five times. 

But are all kernel objects created equal? If a thread object is much 
"heavier" than a mutex or c/v object, (which means, for instance, 
there's much fewer of it), than the cost if much less than five times. 
As I said, I have no idea if that's really the case. Just raising 
questions...

(Oh, and BTW, this cost doesn't need to be added to every thread, only 
to those who need multi joins)