Comments on: Why Windows Threads Are Better Than POSIX Threads http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/ Sun, 20 Jul 2008 16:47:08 +0000 http://wordpress.org/?v=2.5.1 By: matteo http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-12397 matteo Thu, 08 May 2008 14:24:35 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-12397 pthread are open source! You can modify things that you don't like. BTW: This means that its evolution will continue driven by TECNICAL consideration and not by commercial ones. pthread are open source! You can modify things that you don't like.
BTW: This means that its evolution will continue driven by TECNICAL consideration and not by commercial ones.

]]> By: alexf2000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-9654 alexf2000 Thu, 17 Jan 2008 20:55:35 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-9654 Windows have POSIX threads as well. It is called fibers. Windows have POSIX threads as well. It is called fibers.

]]> By: arnshea http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-8893 arnshea Sat, 01 Dec 2007 19:33:09 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-8893 Regarding Windows Threads being "fundamentally broken", the PulseEvent() method doesn't indicate "fundamental broken-ness". PulseEvent() is a convenience function that turns out to be a bad idea because it overlooked a race condition due to kernel async procedure calls. It's also a bad idea because it fails to use a separate synchronization object to coordinate execution. Signaling the event indicates that it is now safe for whichever thread was released to continue execution. If you need to know which thread was released, that's a piece of shared state that itself requires synchronization. In other words, either the thread that was released is implicit (e.g., only a single thread could be waiting to be released) or it shouldn't matter. It shouldn't matter because in the case of a single purpose thread, it's next task is predetermined. In the case of a multipurpose thread, it's next task is shared state that will have its own separate synchronization mechanism. Regarding Windows Threads being "fundamentally broken", the PulseEvent() method doesn't indicate "fundamental broken-ness".

PulseEvent() is a convenience function that turns out to be a bad idea because it overlooked a race condition due to kernel async procedure calls.

It's also a bad idea because it fails to use a separate synchronization object to coordinate execution. Signaling the event indicates that it is now safe for whichever thread was released to continue execution. If you need to know which thread was released, that's a piece of shared state that itself requires synchronization. In other words, either the thread that was released is implicit (e.g., only a single thread could be waiting to be released) or it shouldn't matter.

It shouldn't matter because in the case of a single purpose thread, it's next task is predetermined. In the case of a multipurpose thread, it's next task is shared state that will have its own separate synchronization mechanism.

]]> By: arnshea http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-7475 arnshea Sun, 14 Oct 2007 20:59:26 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-7475 It seems to me that the problem of critically missing a signal/pulse (because your thread was borrowed by the kernel at the time of the pulse) should be handled by using separate synchronization objects and pools for separate tasks. If there is only a single thread that can perform a given task then it should communicate that back to the dispatcher via some other task specific shared state before the dispatcher proceeds. If several threads can perform a given task they should be waiting on a task specific event. Missing a pulse in this case isn't critical (another thread will eventually get to it) but you may take a performance hit (if no other threads are available for the task). If several threads are contending to perform several tasks then, imho, this multipurpose pool should be refactored into several single purpose pools. You already have an operating system, why are you trying to write another? It seems to me that the problem of critically missing a signal/pulse (because your thread was borrowed by the kernel at the time of the pulse) should be handled by using separate synchronization objects and pools for separate tasks.

If there is only a single thread that can perform a given task then it should communicate that back to the dispatcher via some other task specific shared state before the dispatcher proceeds.

If several threads can perform a given task they should be waiting on a task specific event. Missing a pulse in this case isn't critical (another thread will eventually get to it) but you may take a performance hit (if no other threads are available for the task).

If several threads are contending to perform several tasks then, imho, this multipurpose pool should be refactored into several single purpose pools. You already have an operating system, why are you trying to write another?

]]> By: Jeff Sadowski http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-6692 Jeff Sadowski Tue, 11 Sep 2007 22:08:29 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-6692 I found this article and particularly the comments to be very useful. I know pthreads and haven't bothered to learn windows threading for the simple fact of it not being portable. I was wondering(previous to reading) if it would be worth creating a higher level library and switch for usage of one or another depending on the architecture it was compiled on. From what I have been reading it doesn't sound like it would be worth my time to even learn windows threads. Since NT, windows has some(enough for me) POSIX support and from what it sounds like they both work equally well on the side of performance. My goal has changed to writing a higher level api for pthreads. As was mentioned higher level api's come at a cost. Of course my api will be easier for me to use I'm writing it for myself for that purpose. However I will lose a lot of flexibility and might introduce bugs. Its just to play around with threads a little. I might want to write my own c++ wrapper class I'm usually pretty good at this. It is just for fun, for now who knows it might become practical. I found this article and particularly the comments to be very useful. I know pthreads and haven't bothered to learn windows threading for the simple fact of it not being portable. I was wondering(previous to reading) if it would be worth creating a higher level library and switch for usage of one or another depending on the architecture it was compiled on. From what I have been reading it doesn't sound like it would be worth my time to even learn windows threads. Since NT, windows has some(enough for me) POSIX support and from what it sounds like they both work equally well on the side of performance. My goal has changed to writing a higher level api for pthreads. As was mentioned higher level api's come at a cost. Of course my api will be easier for me to use I'm writing it for myself for that purpose. However I will lose a lot of flexibility and might introduce bugs. Its just to play around with threads a little. I might want to write my own c++ wrapper class I'm usually pretty good at this. It is just for fun, for now who knows it might become practical.

]]> By: John Daniel http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-5470 John Daniel Thu, 16 Aug 2007 03:11:26 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-5470 The fundamental difference between the two models is that POSIX only provides mutex and condition locks. Win32 provide a while lot more, the most important of which, for me, are those that allow synchronization between threads. POSIX doesn't do this at all. Unix is designed for multiprocessing. Win32 is designed for multithreading. They can both do the other, but they aren't as good at it. I happen to like multithreading and I'm most comfortable in a real-time environment where I can control how and when threads run. POSIX makes that really hard. Certainly the Win32 implementation has some fundamental flaws, but at least it has something. Is there anything that will let me easily do synchronization points on Unix? I'm thinking about looking into some pre-Unix structures like Semaphores. Is there anything a bit more modern and easier to use? I'm really only concerned with MacOS X at this point. The fundamental difference between the two models is that POSIX only provides mutex and condition locks. Win32 provide a while lot more, the most important of which, for me, are those that allow synchronization between threads. POSIX doesn't do this at all.

Unix is designed for multiprocessing. Win32 is designed for multithreading. They can both do the other, but they aren't as good at it.

I happen to like multithreading and I'm most comfortable in a real-time environment where I can control how and when threads run. POSIX makes that really hard. Certainly the Win32 implementation has some fundamental flaws, but at least it has something. Is there anything that will let me easily do synchronization points on Unix? I'm thinking about looking into some pre-Unix structures like Semaphores. Is there anything a bit more modern and easier to use? I'm really only concerned with MacOS X at this point.

]]> By: Jim Chorn http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-5218 Jim Chorn Mon, 06 Aug 2007 17:28:14 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-5218 What I haven't seen in any of this is a discussion of the implications of these two different interfaces when it comes to light and heavy weight threading. While the POSIX implementation interfaces could do both, the Win32 can only do the heavy weight threading model because of the event queue searching it requires. If you then consider an application that has tight performance requirements where mutex on anything is high overhead you don't use signals, instead, you change your shared memory structures so that each thread has no critical code sections using the multiple writer/multiple reader synchronization model. Instead, your code uses the single writer/multiple reader model (hence no sync needed). While this is low level and not distributed, remember that this is a performance application so you don't want to generalize across a network. The Win32 API's wouldn't, from what I see, know the difference where as the POSIX threads could tell at compile time. But I've been out of the game for a while on this topic so there may be a way to deal with this in another way. Clearly, I'd lean towards POSIX threads for these reasons and no other. If my application doesn't have a tight preformance issue, then this mainly becomes the basic religious discussion of using names for types and the maintenance of the code generated from those decisions. What I haven't seen in any of this is a discussion of the implications of these two different interfaces when it comes to light and heavy weight threading. While the POSIX implementation interfaces could do both, the Win32 can only do the heavy weight threading model because of the event queue searching it requires. If you then consider an application that has tight performance requirements where mutex on anything is high overhead you don't use signals, instead, you change your shared memory structures so that each thread has no critical code sections using the multiple writer/multiple reader synchronization model. Instead, your code uses the single writer/multiple reader model (hence no sync needed). While this is low level and not distributed, remember that this is a performance application so you don't want to generalize across a network. The Win32 API's wouldn't, from what I see, know the difference where as the POSIX threads could tell at compile time. But I've been out of the game for a while on this topic so there may be a way to deal with this in another way. Clearly, I'd lean towards POSIX threads for these reasons and no other. If my application doesn't have a tight preformance issue, then this mainly becomes the basic religious discussion of using names for types and the maintenance of the code generated from those decisions.

]]> By: Clive Darke http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-4111 Clive Darke Sun, 24 Jun 2007 16:29:17 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-4111 I've come late to this discussion, and have not read all the other posts, so forgive me if I repeat what others have said. While I agree with Clay that Windows threads are easier to program, I cannot agree to some of the details. Windows HANDLEs are kernel objects whereas the original pthread mutuex was not (cross process mutexes were added later), so a comparison with CRITICAL_SECTION is fairer. A Windows CS degrades to a (kernel) Event if one thread has to wait. Not sure what happens to a pthread_mutex, a SysV Semephore perhaps? The use of condition variables with a mutex and predicate can be difficult to understand: Windows Events are much easier. However it is interesting to note some new APIs in Vista/Longhorn, a CONDITION_VARIABLE type, SleepConditionVariableCS, WakeConditionVariable, and so on. It will be interesting to see if they suffer from spurious wakeups (which I'm surprised that Clay did not mention) like pthread condition variables do. For completeness, also checkout the new "Slim" Read/Write locks (you mean there are obese ones?) , AquireSRWLockExcluse, ReleaseSRWLockExclusive, and friends. Any opinions as to by Microsoft have added these if their threading model is so complete? I've come late to this discussion, and have not read all the other posts, so forgive me if I repeat what others have said.

While I agree with Clay that Windows threads are easier to program, I cannot agree to some of the details. Windows HANDLEs are kernel objects whereas the original pthread mutuex was not (cross process mutexes were added later), so a comparison with CRITICAL_SECTION is fairer. A Windows CS degrades to a (kernel) Event if one thread has to wait. Not sure what happens to a pthread_mutex, a SysV Semephore perhaps?

The use of condition variables with a mutex and predicate can be difficult to understand: Windows Events are much easier. However it is interesting to note some new APIs in Vista/Longhorn, a CONDITION_VARIABLE type, SleepConditionVariableCS, WakeConditionVariable, and so on. It will be interesting to see if they suffer from spurious wakeups (which I'm surprised that Clay did not mention) like pthread condition variables do. For completeness, also checkout the new "Slim" Read/Write locks (you mean there are obese ones?) , AquireSRWLockExcluse, ReleaseSRWLockExclusive, and friends. Any opinions as to by Microsoft have added these if their threading model is so complete?

]]> By: AlexO http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-3934 AlexO Tue, 19 Jun 2007 12:56:17 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-3934 The post from cppkid sounds a bit strange. From personal experience I can say that debugging pthreads on Linux is very troublesome, I would go as far as calling it an ongoing nightmare. On UNIX (Sun) it is even worse - you actually loose debugging call stack if you program is in a wait state. Personally I enjoy using MS debugger, especially in mt environment; HANDLE data type does not bother me. All of the above might be a personal preference, but I am clearly missing something when somebody actually advocating Linux debugging as being superior. In my personal opinion absence of the decent debugger (or IDE for that matter) is holding Linux back, more than anything else. WaitForXXX naming sounds good to me, but I am not a native English speaker, so I might be missing some hidden lexical problem. "...WaitForSingleObject and WaitForMultipleObjects can easily clash with application code for the lack of any prefix ..." -- in 12 years I never had those 2 functions clash with anything. I am not sure consistent naming convention of pthreads does make it easier. "Also what about the windows CRITICAL_SECTION? This uses a totally inconsistent api " -- I honestly do not get it. What is that inconsistency, cppkid is talking about? And the last thing in the cppkid is usual Linux claim about performance. This is actually what prompted me to respond. When comparing threading performance on Windows and Linux what are the criteria? Does anybody have actual numbers, and testing procedures to compare 2 of them? The post from cppkid sounds a bit strange.
From personal experience I can say that debugging pthreads on Linux is very troublesome, I would go as far as calling it an ongoing nightmare. On UNIX (Sun) it is even worse - you actually loose debugging call stack if you program is in a wait state. Personally I enjoy using MS debugger, especially in mt environment; HANDLE data type does not bother me. All of the above might be a personal preference, but I am clearly missing something when somebody actually advocating Linux debugging as being superior. In my personal opinion absence of the decent debugger (or IDE for that matter) is holding Linux back, more than anything else. WaitForXXX naming sounds good to me, but I am not a native English speaker, so I might be missing some hidden lexical problem. "...WaitForSingleObject and WaitForMultipleObjects can easily clash with application code for the lack of any prefix ..." -- in 12 years I never had those 2 functions clash with anything. I am not sure consistent naming convention of pthreads does make it easier.
"Also what about the windows CRITICAL_SECTION? This uses a totally inconsistent api " -- I honestly do not get it. What is that inconsistency, cppkid is talking about? And the last thing in the cppkid is usual Linux claim about performance. This is actually what prompted me to respond. When comparing threading performance on Windows and Linux what are the criteria? Does anybody have actual numbers, and testing procedures to compare 2 of them?

]]> By: cppkid http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-3271 cppkid Thu, 24 May 2007 20:53:48 +0000 http://softwareblogs.intel.com/2006/10/19/why-windows-threads-are-better-than-posix-threads/#comment-3271 This seems to be a pointless article - one uses the api's available on the platform one is coding for. The main premise of the article is that using one data type HANDLE for every object is quite frankly ridiculace! You might as well use a void* for everything. A typeless api is going to be harder to debug - silly bugs will be missed at compile time! Also the names WaitForSingleObject and WaitForMultipleObjects can easily clash with application code for the lack of any prefix - which every C programmer worth his salt knows. Also what about the windows CRITICAL_SECTION? This uses a totally inconsistent api. Win32 is a hodge podge api and to make matters worse the performance of the Win32 threads is very poor especially when compared with a POSIX based system such as Linux or OSX. This seems to be a pointless article - one uses the api's available on the platform one is coding for. The main premise of the article is that using one data type HANDLE for every object is quite frankly ridiculace! You might as well use a void* for everything. A typeless api is going to be harder to debug - silly bugs will be missed at compile time! Also the names WaitForSingleObject and WaitForMultipleObjects can easily clash with application code for the lack of any prefix - which every C programmer worth his salt knows. Also what about the windows CRITICAL_SECTION? This uses a totally inconsistent api. Win32 is a hodge podge api and to make matters worse the performance of the Win32 threads is very poor especially when compared with a POSIX based system such as Linux or OSX.

]]>