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

From: Johan Nilsson (r.johan.nilsson_at_[hidden])
Date: 2007-03-26 09:18:40

Yuval Ronen wrote:
> 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?).

Yes, 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?

When the last handle to the thread is closed, the kernel thread structure 
must be cleaned-up. Whether that results in significant overhead or not 
depends on the implementation. It could possibly be as simple as moving the 
structure pointer to a "free list". I tried to search through my copy of 
"Inside Windows 2000", but didn't find anything fast enough to give you a 
reply ...

Still, yes, an extra kernel mode transition.

> 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.

Is it possible to implement join reliably/effectively under Win32 without 
resorting to kernel objects? All kernel objects still need to have their 
references (Win32 handles etc) closed to avoid resource leakage during 
process lifetime.

/ Johan