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

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2007-03-26 05:40:04

Johan Nilsson wrote:
> Yuval Ronen wrote:
>> Peter Dimov wrote:
>>> Howard Hinnant wrote:
>>>
>>>> N2184 takes the minimalist approach.  It is easier to add
>>>> functionality (and the associated expense) than to subtract it.
>>>> There are many things the N2184::thread does not directly support.
>>>> I believe this is a feature, not a bug.
>>> This is true under the assumption that we need to target the least
>>> common denominator. Try/timed joins for example come for free on
>>> Windows. So you are imposing an unnecessary mutex+cv overhead for
>>> everyone wanting to use try/timed joins there.
>>>
>>> I've decided to adopt a different approach and suggest a way to
>>> equalize ('harmonise' in EU terms :-) ) the platforms via the join2
>>> extensions. In a perfect world, this would lead to everyone enjoying
>>> _zero overhead_ try/timed joins in a few years once pthread
>>> implementors adopt the extensions.
>>>
>>> Yes, I agree that this can be considered idealistic; but the other
>>> option is to not even give them a chance to offer the functionality
>>> as there would be no portable C++ way to take advantage of it.
>> I'm far from being an expert on the Windows internals, but maybe what
>> seems to "zero overhead" try/timed join is not really zero overhead,
>> and
>> the overhead is there, just hidden somewhere inside. If that's the
>> case,
>> then the "idealistic" way to go is to get Windows to supply a true
>> zero overhead join.
> 
> Basically you're just waiting for a thread handle to become signalled, much 
> as waiting for an event, mutex or whatever. No more overhead than that, 
> AFAIK.

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. So in case of a 
single joiner, it seems pthreads is better, at least with respect to the 
CloseHandle call (and there might be other issues). Is the CloseHandle 
overhead significant? I really don't know. If it's not much, and there's 
really a way to implement zero-overhead multi/try/times joins, then that 
would certainly change my perspective.