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
>>> 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?).
> 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
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
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk