Yuval Ronen wrote:
Johan Nilsson wrote:
Yuval Ronen 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
Peter Dimov wrote: 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