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