Why Windows Threads Are Better Than POSIX Threads

By Clay Breshears (Intel) (75 posts) on October 19, 2006 at 8:00 pm

I've used both POSIX threads (Pthreads) and Windows threads APIs, and I believe that Windows has the better programming model of the two. While each threading method can create threads, destroy threads, and coordinate interactions between threads, the reason I make this claim is the simplicity of use and elegance of design of the Windows threads API. This is all from the perspective of multithreaded code developers or maintainers. Let me illustrate with a few examples.

Simplicity of data types. In Pthreads, each object has its own data type (pthread_t, pthread_mutex_t, pthread_cond_t, etc.) while, in Windows threads, there is pretty much just the one type: HANDLE. For Pthreads this means different functions are used for working with each object type. Reading and understanding Pthreads code written by someone else can be straightforward. However, this does mean that the programmer must know the number, order, and type of parameters for all the different functions. On the other hand, because of the use of the same type for different objects, there is a Create* function for each different object and a corresponding Release* function for most.

Perhaps the biggest advantage of a single object data type is that there is only the one function needed to make a thread block while waiting for an object: WaitForSingleObject. Thus, only one set of parameters needs to be known regardless of whether the code is waiting on a thread, a mutex, a semaphore, or an event. The related function, WaitForMultipleObjects, is just as simple to use and easily overcomes the problem of needing to wait for multiple thread terminations one function call at a time (pthread_join) that Pthreads requires. While some may say that using a single data type for many different objects can lead to confusion when used in WaitFor* calls, programmers should set the name of the handle such that it is readily apparent whether the code is expecting a thread termination, an event to be signaled, or a mutex to be released.

WaitForMultipleObjects functionality. Besides being able to block a thread waiting for multiple thread terminations in a single call, the programmer can actually wait for any out of a set of threads to terminate. That is, even when only one thread has completed, the WaitForMultipleObjects function can be set to return and indicate which thread triggered the return. If there is specific "clean up" processing that depends on the identity of the thread that finished, this can be done before returning to wait on the remaining threads. This clean up processing will be done in the most efficient order possible, soon after each thread terminates, no matter in what order this happens. Pthreads can perform similar post-processing, but will need to wait for the threads to terminate is some fixed order. So, even if the last thread finishes first, it must wait for all the post-processing of the previous threads to be completed.

Because different objects all use the HANDLE type, a call to WaitForMultipleObjects can be set to wait for any combination of threads, mutexes, semaphores, and/or events. This feature can give the programmer a flexibility that cannot be easily (if at all) duplicated in Pthreads. As an example, I've written Windows code that used an array to hold both thread and event handles to support a threaded search through data. The ideas was to signal the blocking thread if the item being looked for was found and when the searching thread terminated; if the object was not found, the searching thread terminated without setting the event. By waiting for either handle to cause WaitForMultipleObjects to return, a simple switch statement could determine if the item had been found (and process the data) plus perform some post-processing computation upon the termination of the searching thread (regardless of whether the search was successful).

Persistence of signals. To paraphrase a classic conundrum in terms of Pthreads: If a thread signals a condition variable and no other thread is waiting, does it make a sound? The signal is lost if there is no thread waiting on the condition variable. For this reason, it is mandatory to set up a while loop to test a conditional expression (used to prompt a signal), and that requires getting a mutex involved to protect the data within the conditional expression and any changes to that data, and don't even get me started about spurious wake ups. Sheesh!

For Windows threads, once an event is in the signaled state, it stays signaled. In other words, when that tree falls, it continues to scream in pain until someone comes along to hear it. It is up to the programmer to ensure the proper switching of Windows events from the signaled to unsignaled state. Part of this involves setting the attributes of the event correctly and being sure to reset manual events as needed. All in all, this seems more convenient and simple. Besides, once the specified conditions have been achieved in order to signal the event, it's not like they can be unachieved later. Under Pthreads, if you blink, you've missed it.

These are just some of the reasons that I think Windows threads is a better threading API than Pthreads. What do you think? Do you have other reasons to prefer Windows threads? Or do you think Pthreads is the better threading method? I'd like to hear about your preferences.

--clay

Categories: Multicore
Tags: p=np

Comments (71)

By ingconti@ingconti.com on October 23rd, 2006 at 3:23 pm
I PERFECTLY agree.
Win Threads are better, faster, and with BETTER ASPIs.
Posix Pthreads are slower (on windows...) and with ridicolous APIs.
Unix can be nice, but NOT on some areas.
For example You cannot terminate or kill other threads... in a decent manner...
Anyway on Win32 PThreads are mapped to Threads (I read soemwhere.. ) so they are slower.

By neverlive on October 26th, 2006 at 1:31 pm
I think that sometimes you need to know the inside things and consider more details to enhance the performance in practical parallel programming. WHile the Win API provides more benifits on ease of use, it also limits what you can do and what you will never know.

Anyhow, simply comparing them and lead to a conclusion seems to be a little bit cursory, and doing so is quite similar to those people did on comparing c++ & java----one is safer, hides more details while another gives developer more freedom.

By David Schwartz on December 28th, 2006 at 8:24 pm
I have to say that I 100% fundamentally disagree with the major premise of your comparison. POSIX threads are a low-level API and Windows threads are a high-level API. Stating all the advantages of a high-level API while stating none of the advantages of a low-level API just isn't fair.

Yes, it's harder to code to a lower-level API. But you don't pay the penalties for the higher-level API when you don't need its features.

You can implement handles easily in pthreads if you need them. But it has a cost because internally you have to check what type of handle it is and then decide what operation to do. If one piece of code is *always* going to operate on a mutex, why pay that cost? You have *no* choice with Windows threads. You can use a library that provides that capability with POSIX threads easily.

Same goes for "WaitForMultipleObjects". You can code that capability trivially in pthreads. However, it has a cost. Ultimately, when an object is signalled, you have to check what other objects the threads that are woken might be waiting for and remove it from those wait queues. With Windows, you pay that cost with every waitable event all the time. With pthreads, you can implement that functionally and pay its cost *if* you need it but don't pay that cost if you don't.

Pthreads is light and fast. It provides only the primitives, but it is not even the slightest bit difficult to implement more complex stuff on top of it. Windows makes you pay the cost of the complexity whether you want it or not. But if you have decided that cost is worth bearing even when you don't need it, you can just pick the library of your choice or with the exact features you want to layer on top of pthreads.

But the worst part, IMO, is that the Windows API is fundamentally broken. Pthreads may be missing functionality, but that can easily be added. Windows threads just plain don't work right.

Perhaps the best example to show this fundamental brokenness is this: http://blogs.msdn.com/oldnewthing/archive/2005/01/05/346888.aspx

By Clay Breshears on January 4th, 2007 at 11:34 pm
David -

I disagree with your characterization of Pthreads being "low-level" when the Windows threading API is "high-level." IMO, these are at an equivalent level, as far as the programmer using them is concerned. I do agree with your second paragrah, but don't think that it applies here. Let me see if I can explain my view point.

Consider two electric saws: a hand-held circular saw and a radial arm saw. Both cut wood and both require some interaction with the operator. The radial arm saw may have more features (laser alignment, easily adjustable to make cuts at any angle, vacuum to remove sawdust, etc.) and the hand-held saw has greater mobility. Is the radial arm saw a "high-level" tool where the hand-held model is "low-level"? I don't think so. It may be easier to do some tasks with one saw than with the other, but they can basically do the same thing.

With regards to programming, there is an easy way to distinguish "low" and "high" methods and libraries. High-level languages have obvious advantages over assembly language. It's easier for humans to code and understand "A = B + C" than to write out the load-add-store trio required to do the same thing in assembly. And which would you rather do, as a programmer, hand code PEEK and POKE instructions to insert data values into memory or call a DrawLine function?

Windows threads has some extra bells and whistles and, therefore, offers some shortcuts to doing certain operations. However, for the most part, I would rate Pthreads and Windows threads as being roughly equivalent in programming complexity to implement a given algorithm. Sure, the lean and mean implementation of Pthreads may outperform the bells-and-whistles-heavy Windows threads in head-to-head tests. That doesn't really have anyting to do with one being at a "higher" level than the other.

I appreciate you taking the time to disagree with me, but your premise doesn't work for me. As for the Windows API being broken, I'm not sure I could comment intelligently on that (assuming I've been commenting intelligently up to this point, of course).

--clay

By JoelKatz on January 11th, 2007 at 10:47 pm
I think you are assuming that I am claiming that the WIN32 threading API and the pthreads API are as far apart in terms of level as assembly and C++. I am not saying quite that. I am saying that the pthreads API is a lower-level API than the WIN32 API.

A good example is the unified handle structure. Higher-level APIs often have unified mechanisms that allow you to treat different data types as if they were the same.

Consider the following C code:
c=a+b;
Is this a floating-point addition or an integer addition? You can't tell because the C language allows you to use the same code for two very different internal operations because they have the same meaning.

Fortunately, in the case of C, this has no overhead because the types can be determined at compile time. But if the types had to be determined at run time, this convenience would come at a cost. That still wouldn't be bad -- the convenience might well be worth the cost.

Win32's unified handles mean that the meaning of an operation has to be determined at run time. This may have some added convenience, but it also has added cost. It is unfair to look at the difference in convenience will ignoring the difference in cost.

You can add unified handles on top of pthreads if you want it. It is not particularly difficult. All you have to do is replicate the code that Windows already has. The difference is that in windows, you get it whether you want it or not.

And, again, an interface that is better in some ways but is broken in very fundamental ways is just not going to be better overall. The Windows OS fundamentally breaks user-space threading by "borrowing" application threads and breaking the semantics of fundamental threading operations by doing so.

For example, "SignalObjectAndWait", which was supposed to fix the fact that it's damn near impossible to implement condition variables on WIN32 is so fundamentally broken that you can't use it. (Being able to atomically signal and wait is of no value if the OS can "unwait" your thread without telling you.)

By Clay Breshears on January 29th, 2007 at 10:40 pm
Yes, I was thinking you meant a larger gulf than you originally intended. I consider OpenMP (and TBB) to be at a higher level than either of the explicit threading models. Putting some pragmas and other "hints" in the code, then getting the compiler to create code that does all the nitty gritty details, is quite high-level.

I understand the advantages of compile-time evaluation over run-time evaluation. However, I don't think that the situation is a dire as you might paint here. Wouldn't a simple case/switch statement be able to choose which way to process an object being waited for (at run-time) under Windows? How much extra overhead is this? I don't know, but I suspect that it can't be all that much. If I were to implement the "unified handles" in Pthreads, this is how I would do it. Even then, though, I believe that we'd be comparing oranges and tangerines. Close, but still not enough alike to be able to do a direct comparison.

I'm in whole-hearted agreement about broken interfaces, even though I'm hard pressed to come up with an example from my career where I found such a case. I usually hear from others that say "I'll never use X again, because Y is broken," and then find out it's some corner case that their code exercises. Yes, it is broken, but only if you need that corner case functionality. Is that any reason to condemn something outright? Probably, but if something worksm every single time you use it and you never encounter the broken corner case, you'd never know. (Anyone remember the FDIV bug in Intel microprocessors in '95? There was a 1 in 360 billion chance of getting the wrong answer in the fourth significant digit. That was certianly enough for Intel to replace any and all chips.)

Rather than complain about "SignalObjectAndWait" not working, I would ask why anyone would need condition variables in Win32 threads? It would make translating code from Pthreads to Windows easier, of course. Surely, there must be some other way to translate/recode anything in my Pthreads code that is not supported directly by Win32. I mean, I don't expect a "move corresponding" feature in C++ so I can more easily translate/re-write my COBOL programs for more modern platforms. I see Fortran creeping closer and closer to C with each new revision and update to the spec.

Will there be a time when we will be able to write in one language with one threading interface (or at least translate easily from one to another)? Would that be a good thing?

--clay

By anonymous coward on February 26th, 2007 at 7:07 am
How can you justify this?

A couple of years ago you wrote an essentially identical post which gave the opposite conclusions.

http://softwarecommunity.intel.com/ISN/Community/en-US/forums/post/840096.aspx

It starts:

I've used both POSIX threads (Pthreads) and Win32 threads APIs and I believe that Pthreads has the better programming model of the two. While each threading method can create threads, destroy threads, and coordinate interactions between threads, the reason I make this claim is the simplicity of use and elegance of design of Pthreads. Let me illustrate with a few examples.

By Slashdot Reader on February 26th, 2007 at 7:18 am
I've used both POSIX threads (Pthreads) and Win32 threads APIs and I believe that Pthreads has the better programming model of the two. While each threading method can create threads, destroy threads, and coordinate interactions between threads, the reason I make this claim is the simplicity of use and elegance of design of Pthreads. Let me illustrate with a few examples.

Separate data types. In Pthreads, each object has its own data type while in Win32 threads there is a mix of handles and separate types. For Pthreads this means different functions are used for working with each object type. Reading and understanding Pthreads code written by someone else is straightforward and less apt to lead to confusion. On the other hand, because of the use of the same type for different objects, when a Win32 program uses WaitForSingleObject, it may not be readily apparent if the code is expecting a thread termination, an event to be signaled, or a mutex to be released. This also illustrates my next point.

Unambiguous functionality. I've actually seen Win32 code that used an array to hold both thread and mutex handles, then wait on those handles and execute different code paths depending upon which handle was signaled first. Correct implementation, yes, but a tough nut to understand on a first reading. While Pthreads may have more functions defined (around 60) than Win32 threads (I counted close to 30 thumbing through a book on Win32 threads programming) Pthreads has a single function to create threads. If you include the C Runtime Library, there are three separate ways to do this for Win32 threads.

Persistence of signals. It is up to the programmer to ensure the proper switching of Win32 events from the signaled to unsignaled state. Part of this involves setting the attributes of the event correctly and resetting manual events. If either of these is not done (and I've been guilty of not properly initializing or resetting events many times), the application will not function as expected. Tracking down this error can be difficult even with debugging tools. Under Pthreads, signals to condition variables are either "caught" by waiting thread(s) or discarded. However, use of a well known coding structure at each access of a condition variable will ensure no signals are "lost" by threads that may not be waiting at the exact time of signaling.

These are just some of the reasons that I think Pthreads is a better threading API than Win32 threads. What do you think? Do you have other reasons to prefer Pthreads? Or do you think Win32 threads is the better threading method? I'd like to hear about your preferences.

By Dave on February 26th, 2007 at 7:40 am
Oooo, this should be fun to watch.

By xxxxxxxx on February 26th, 2007 at 7:59 am
Here's another article on the same subject:

http://softwarecommunity.intel.com/ISN/Community/en-US/forums/post/840096.aspx

By Anonymous on February 26th, 2007 at 8:01 am
We get it. Same author, exact opposite conclusions. Stop posting links, slashdotters.

By Nils H on February 26th, 2007 at 8:15 am
One clear disadvantage that I see with the windows way of programming is the allover general use of HANDLE for everything from mice to dandruff. You are never sure when reading the code what the HANDLE really is, it's like using (void *) everywhere in your code for all types of data.

The point behind the specific data types in pthreads is that you as a programmer will get code that is a lot easier to maintain over time by different programmers.

By Sam Moffatt on February 26th, 2007 at 8:17 am
>Wouldn't a simple case/switch statement be able to choose which way to process an object being waited for (at run-time) under Windows? How much extra overhead is this? I don't know, but I suspect that it can't be all that much. If I were to implement the "unified handles" in Pthreads, this is how I would do it.

But you're running that switch statement on _every_ thread/ mutex as you progress. Sure for an individual application this may only be a small number, but what happens when you start to extrapolate that across the entire operating system. Your small overhead massively explodes in number for every single thread/mutex/etc. This is the point I believe is trying to be made that the effect extrapolates out to the larger scale even worse (and if you're trying to write really tight multithreaded code (e.g. mmorpg say) then that switch statement might mean a few frames a second more to the rendering engine...but you don't get that choice).

By Who cares? on February 26th, 2007 at 8:29 am
So, this seems to me to be just another "I like these features, so everything else sucks" article. USE WHATEVER YOU NEED TO USE TO GET THE JOB DONE RIGHT. If XYZ is broken, don't use it, use ABC. If ABC is more complex than you want, use XYZ, providing it will do the job. Use what works, COMMENT YOUR CODE (this includes the author's recommendation that you name your handles appropriately), and it will all work out in the end. It's generally a waste of time to argue that one is better than the other in all cases, because someone will find an exception to your rule.

By Dude on February 26th, 2007 at 8:36 am
See http://softwarecommunity.intel.com/ISN/Community/en-US/forums/post/840096.aspx
for an article from the opposite viewpoint - by the same author, and with only a few words changed around.

By Nice Guy on February 26th, 2007 at 8:41 am
Hahahahah..pwned

By George on February 26th, 2007 at 8:42 am
Well, I was reading another article that said just the opposite...
http://softwarecommunity.intel.com/ISN/Community/en-US/forums/post/840096.aspx
So, which is right? PThreads or W32Threads?

Thanks!

By Bahah hahahaha on February 26th, 2007 at 8:43 am
$careerCredibility=0;

Thread that one, Clay.

By Earl Olsen on February 26th, 2007 at 8:50 am
It looks like you posted an almost identical article back in 2003, except that you express the exact opposite opinion.
http://softwarecommunity.intel.com/ISN/Community/en-US/forums/post/840096.aspx

By Sutoka on February 26th, 2007 at 8:53 am
I have to agree with "Dude" on this one. This blog entry is pretty much a copy of http://softwarecommunity.intel.com/ISN/Community/en-US/forums/post/840096.aspx except pretty much the reverse (the reasoning why pthreads are better in that post, are the reasons why pthreads are worse in this one). If your opinion simply changed over the years it would have been better to link back to the previous one and say WHY you think that is no longer the case.

By ITblog : Why Posix threads are better than Windows ones or wait .. why Windows are better than Posix ones ... on February 26th, 2007 at 8:58 am
[...] are better than Posix ones ... Two articles, same author. A game is: find differences! Why Windows threads are better than POSIX threads? vs Why POSIX threads are better than Windows threads? Intel communities ... yeah, [...]

By Foo Bar on February 26th, 2007 at 9:05 am
This guy is deleting responses.

His paper on how wonderful Windows threads are is nearly word-for-word identical to another paper he wrote just a couple years ago on POSIX threads. This guy is a corporate shill for Intel.

Check Slashdot. It's all there in black and white.

By Foo Bar on February 26th, 2007 at 9:08 am
$careerCreditibility=0; # Corporate shill for Intel.

By ravalox on February 26th, 2007 at 9:12 am
Guys, this is years apart. Years of experience in a field are easily enough reason to have a change of opinion. Let's not point out the contradiction and instead discuss the issue at hand; pthread complexity versus windows threads.

By Foo Bar on February 26th, 2007 at 9:17 am
The bulk of this guy's PhD work is in POSIX threads. I find it hard to believe a 20 year expert in the field who's pubished numerous papers on pthreads is suddenly going to change his tune, or be totally oblivious to the Win32 model.

For fuck sake, Windows doesn't even have fork()!!

Pay no mind to the fact that there's a massive marketing push underway from Microsoft and their partners (Intel, among them). Nooo.. Nothing to do with it. Nothing to see here, move along.

Yeesh.

By thePoint on February 26th, 2007 at 9:19 am
"this is years apart. Years of experience in a field are easily enough reason to have a change of opinion."

The point being: it is somewhat less than honest to reuse your argument for A>B as the reason why B>A, regardless of the amount of time passed, without providing some sort of disclaimer. As in 'I said before that A>B because of xyz, but now I feel B>A and this is what changed my mind: ...'

Would that have been so difficult? It would have saved a great deal of embarassment at the hands of Slashdotters, I am sure.

By Knodel on February 26th, 2007 at 9:32 am
The interesting question, in addition to "Why Clay Flip-Flopped" is "Who was the anonymous slash-dotter who pointed it out, and what was his motivation?"

By SebaSOFT on February 26th, 2007 at 10:29 am
Pretty cheap to change the words, make a mea culpa or something, but not only change words...

By HotelTango on February 26th, 2007 at 10:29 am
Find and Replace is a powerful tool. No wait...Replace and Find is a powerful tool.

By hi on February 26th, 2007 at 10:48 am
hello

By Decio on February 26th, 2007 at 11:10 am
What I think?!
With that changing opinion?!
I think this guy have not enough experience to publish an article on threads.

By Orthogonal on February 26th, 2007 at 11:11 am
As someone pointed out in Slashdot:

( Pthreads >= Win32 threads ) and ( Win32 threads >= Pthreads ) => Pthreads = Win32 threads

But please, write us an article on this!

By Max on February 26th, 2007 at 12:25 pm
Well, I guess Wintel isn't a myth after all.

By Clay Breshears on February 26th, 2007 at 2:06 pm
Phew! Quite the tempset in a teacup here and over on slashdot.org. (To paraphrase Oscar Wilde, "There's only one thing worse than being talked about, and that is being talked about on slashdot.org".) I thought I'd pop in to clear a few things up. Since my credibility appears to be running on empty at the moment, or as one post so eloquently put it...

$careerCreditibility=0;

...I've got next to nothing to lose.

Yes, I've written two articles on the relative merits of Pthreads and Windows Threads. The more recent is a direct copy of the previous with the arguments reversed. Why? Several possbile reasons come to mind: 1) I've changed my mind since the first article was posted and I'm lazy, 2) I'm taking up a more unpopular position just to get a bigger response than the first article got, or 3) I was drunk then (or am drunk now) and didn't know what I was talking about. I admit, I am a flip-flopper (I also no longer think girls are "icky," I readily eat my broccoli, and I think dark beer is quite delicious). Before coming to Intel, I worked with large UNIX systems and used Pthreads. In fact, I've even written a Fortran interface for Pthreads. Soon after joining Intel, when threaded programming became more of a focus for the group I was in, I needed to learn Win32 threads. It was strange and different while similar enough to be tantalizingly frustrating. This resulted in the first post. After three years of working with Windows Threads, I've come to appreciate them better. (In my book, though, OpenMP is superior to either explicit threading API.)

Yes, I've played the part of corporate shill in the past. I've admitted as such in other blog comments (see
http://softwareblogs.intel.com/2006/11/14/theres-threads-in-them-thar-hills/). This was not one of those times. I plagarised my previous post with cut-and-paste just to get something written and put out. As I said, I'm lazy. (Should I have referenced the previous article? Probalby. I've been caught in a The Daily Show moment aking to the Vice President shown saying he never said something and then we get a clip of him saying exactly that from 2-3 years ago. Electronic posting, like video tape, seems to persist long after we think anyone will be looking.)

No, I've not been compensated in any way for any of my comments here or in the Software Forums. Okay, I did get a $5 Starbucks gift card for doing the blog, but everyone that was blogging at the time got one (I assume). Microsoft has not given me anything (except a pretty keen folder when I taught a class to them in North Dakota in 2002), and Intel only pays my salary. I've gotten some heat from internal sources about my comments and criticism about some of their marketing efforts (i.e., http://softwareblogs.intel.com/2006/11/10/pounding-my-virtua.....al-podium/) and one of their recent threading products (i.e., href="http://softwareblogs.intel.com/2006/12/18/threading-building-blocks-solution-looking -for-a-problem/). So, nothing that I write here has been passed through or approved by anyone from Intel before it sees the light of your monitor.

Yes, I'm a real person. That's really me getting kissed by a stainless steel fish.

No, I have not removed any comments to this blog. If comments have been removed, it was not by me. I get an email copy of each and every comment that is posted to blogs that I've written, so I've seen and read them all.

No, I didn't put the original post on slashdot.org. While it now strikes me as a good marketing ploy, I don't think even I would be daft enough to point out two inconsistent positions written by the same person. I would have pointed out the potential processes vs. threads brouhaha that could be an interesting debate. (See http://softwareblogs.intel.com/2006/11/15/dont-thread-the-end-of-the-free-ride/ and http://softwareblogs.intel.com/2007/02/11/multiprocessing-whats-in-it-for-me/ .)

In summary, love me, hate me, remain ignorant of me, I don't mind either way. If I've lost all possible credibility with you, I hope you'll give me a chance to win you back with my most recent blog (http://softwareblogs.intel.com/2007/02/23/do-we-need-another-parallel-programming-languag e/) and future posts. If you want to continue with the ad hominem attacks, please take them somewhere else, like back to slashdot.org. If you want to debate the merits of Pthreads vs. Windows Threads, I invite you to stay and speak up. Ultimately, that is what I did it for: to start a dialog about threading and how best to do it.

--clay

By Kurt Fitzner on February 26th, 2007 at 2:37 pm
Clay Breshears: "Ultimately, that is what I did it for: to start a dialog about threading and how best to do it."

Ahhh... I get it. It was all in the name of dialog. The important thing isn't an accurate portrayal of the relative merits of two technologies, it is in spurring dialog about them.

I'm not sure taking two diametrically opposed positions and arguing them with essentially the same language piped through a logical NOT is the way to spur dialog. Your credibility took more of a nose-dive in my estimation by your explanation than by the actual act of posting the two articles. Say what you believe. If what you believe changes, say why. Saying something just to get a reaction is irresponsible.

By Silpheed on February 26th, 2007 at 3:13 pm
Leave Clay alone. Attack the ideas, not the person. And can we please remember that this is about a programming preference, not starving children in Africa or gay marriage or anything thats consequential on a moral basis. The statement that its "irresponsible" to say something "just to get a reaction" is ludicrous given the context. Its Clay's blog. And its insignificant. Relax.

By ravi on February 26th, 2007 at 3:30 pm
man, you are featured on slashdot now.. for contradicting yourself...why do you do these things?

By Tony Kimball on February 26th, 2007 at 4:08 pm
Pthreads and Win32 threads can do the same things. In some cases Pthreads are superior, and in others, Win32 threads are superior. However, Pthreads have a HUGE advantage: They work pretty well everywhere. Win32 threads just don't work at all unless you're on a Win32 system.

Nolo contendere.

By Slashdot: News for nerds, stuff that matters on February 26th, 2007 at 5:04 pm
An anonymous reader writes "It's interesting when different people have different opinions. While I was searching for something on Intel's website, I came acrossan article on why Windows threads are better than Posix threads. Curiously, I also came across this article on why Posix Pthreads are better that Win32 threads. The thing is, both of these articles are written by the same author! So who is right (metaphorically speaking?), or what has changed since the first

By Slashdot: News for nerds, stuff that matters on February 26th, 2007 at 6:20 pm
An anonymous reader writes "It's interesting when different people have different opinions. While I was searching for something on Intel's website, I came acrossan article on why Windows threads are better than Posix threads. Curiously, I also came across this article on why Posix Pthreads are better that Win32 threads. The thing is, both of these articles are written by the same author! So who is right (metaphorically speaking?), or what has changed since the first

By Josh Bancroft on February 26th, 2007 at 9:36 pm
Great response to a potentially explosive issue, Clay. I was getting worried, reading the evidence and the comments from the Slashdotters - thought I might have to stage a Blogger Intervention(TM).

But your response was top notch, and above all, honest, which is what counts.

When we finally get together, you'll have to tell me all about this one. Sounds like a good story.

Everyone else, please feel free to continue to debate the topic, but lay off the ad hom attacks, OK? Let's try to follow the "living room" rule of behavior here.

By One way to get some blog attention, and how to recover » TinyScreenfuls.com on February 26th, 2007 at 9:51 pm
[...] (Why POSIX Threads are Better Than Windows Threads), but from the opposite side of the argument (Why Windows Threads are Better Than POSIX Threads). This apparent reversal got picked up on Slashdot, even though the latest post is 5 months old, [...]

By Intel® Software Network Blogs » Blog Archive » One way to get blog attention, and how to recover on February 26th, 2007 at 9:56 pm
[...] (Why POSIX Threads are Better Than Windows Threads), but from the opposite side of the argument (Why Windows Threads are Better Than POSIX Threads). This apparent reversal got picked up on Slashdot, even though the “new” post is 5 [...]

By Dave on February 26th, 2007 at 10:07 pm
Ok, so reading the articles one after another is a little confusing -- like perhaps Clay was hit with a stainless steel fish in between the two writings. Or perhaps his eyes were opened to a new point of view.

I unfortunately can't really debate this -- I've only really had experience with pthreads, and even that quite recent. I have to agree with a previous comment though -- at least with pthreads, you aren't confined to a win32 platform. I don't have anything particular against M$ -- if they could just produce a reasonable product (apart from SQL Server), and perhaps just be a little less like NERV from the movie "Antitrust", then I suppose I would tolerate them (though I still wouldn't buy something (like an OS) that I can get for free, especially when I can tinker with the free one). But I suppose it's again a matter of personal choice.

Clay, I think you should have linked to the previous article, and explained *why* you had a mindshift. People's ideas and preferences can change -- but if you are going to write two articles from totally different standpoints and expect to be credible, you have to either be able to point at one and say "I was smoking crack when I wrote that", or at least say "Ok, so there are good and bad points for either side".

By WNight on February 26th, 2007 at 11:47 pm
I agree, kinda slack Clay. Especially, as the other poster said, your response.

How do the same arguments apply to pthreads as Win32 threads? How can simply swapping one for the other be a valid article, even if it matches your views now?

I demand a full refund.

By randomboy on February 27th, 2007 at 2:23 am
Yeah, but I like the way it ends better:

"Persistence of signals. It is up to the programmer to ensure the proper switching of Win32 events from the signaled to unsignaled state. Part of this involves setting the attributes of the event correctly and resetting manual events. If either of these is not done (and I've been guilty of not properly initializing or resetting events many times), the application will not function as expected. Tracking down this error can be difficult even with debugging tools. Under Pthreads, signals to condition variables are either "caught" by waiting thread(s) or discarded. However, use of a well known coding structure at each access of a condition variable will ensure no signals are "lost" by threads that may not be waiting at the exact time of signaling."

This is pretty much the same description as in the last paragraph of the current article, but with opposite conclusions. Not that there's anything wrong with contradicting yourself a couple of years later...

By David Schwartz on February 27th, 2007 at 3:17 am
I think you radically underestimate how critical performance is in threading primitives. A mutex, for example, that requires no external function call in the uncontended case can make a *huge* difference. The overhead of a switch/case statement in your threading primitives means more register pressure, a bigger cache footprint, and probably even more function calls -- all right in your most critical pathways.

As for why you need condition variables, the answer is that they're the most efficient way to solve a very large class of real-world problems. But I think you underestimate how fundamentally WIN32 threads are broken and how hard it is to design a WIN32 synchronization scheme that doesn't risk missed wakeups. The short version of the problem is that no matter how sure you are that a thread is blocked on something, it may not really be (because the OS may have 'borrowed' it) so you can never be sure it caught a wakeup, so all WIN32 wakeups must persist until the think woken up acknowledges them.

By pwned on February 27th, 2007 at 4:40 am
I was here

By slashdot plag on February 27th, 2007 at 7:06 am
same author:
http://softwarecommunity.intel.com/ISN/Community/en-US/forums/post/840096.aspx
http://softwareblogs.intel.com/2006/10/19/why-windows-thread.....x-threads/
Initial (2003) article:

And in the later article:

It's not plagiarism because he copied from himself and just added a few edits, but c'mon... how lazy of a shill can you be?

By [Slashdot] Stories for 2007-02-27 at Kaizenlog on February 27th, 2007 at 9:46 am
[...] [...]

By AlexO on February 27th, 2007 at 10:00 am
I would like to add my part to the discussion as a person who actually does program with both pthreads and Win32 threads. I also admit that due to my experience I have heavy bias toward Win threads

First for the interface -- I strongly believe interface arguments are kind of useless , because it is a matter of taste and convenience. They are hardly measurable concepts. I personally prefer windows interface , it seems cleaner to me and easier to use. But again I readily admit that I spent 15 years developing on Windows and only 3.5 on Linux.
I noticed that argument is veering off the real life scenarios a bit. Let's really compare apples to apples

Event vs. Conditional variable. Event's pulse functionality is unreliable no doubts about that, it says so in MSDN. In addition to that pthread_cond_broadcast is very difficult conceptually, even experienced Unix developers make mistakes implementing it. Probably this affects my way of thinking, but I hardly can imagine situation when I do need to wake all the threads at once. In my observation spontaneous thread wake up is extremely rear(though possible) event on Windows and somewhat business as usual on Linux. While that event is annoying it is easily handled on either system. Conditional variable is difficult to use because concept actually involves a lock (mutex) which arbitrary locked and unlocked through the system calls, and interface is comparatively bulky. Again while inconvenient from Windows view point, it is not a rocket science. Auto reset vs. manual reset functionality is not easy on Linux either, on Windows you just choose the one you want.

WaitForSingleObject is very convenient function to check state of any handle. It is extremely convenient to check if thread is alive, there is simply no similar functionality in pthreads. Yes , yes I know "use pthread_getschedparam" or some other obscure sequence of calls -- it just does measure it is not as reliable and in some cases outright dangerous

WaitForMultiple... is extremely useful to wait for multiple threads or multiple objects of any kind. Nobody here mention how to do that on Linux. I suspect it involves usage of a semaphore or something like that.

I am surprised that nobody even brought up the recursive locks. To create a recursive lock on Linux you actually have to specify number of recursion, which in my personal view is unacceptable, and makes that functionality useless. Mutex and critical section get it for free on Windows.
Nobody discussed also that windows do not have read-write locks. Pthreads gives it as a part of API.

Signal handling is pretty much missing from Windows, with the exception of pathetic Ctrl-C. As a windows programmer I do not see what the big deal is. From what I observe in Linux world signal handling is left over from single thread programming, and rarely used in multithreaded programs. I might be wrong , but I challenge anybody to produce usable example of proper processing SIGPIPE in multi-threaded, multi-socket application. The very existence of pthread_sigmask suggests a problem.

Another area missing form Linux -- Interlocked.... Cheap, efficient way to swap bytes in memory, but it is not really required, I guess.

Windows on another hand are missing (not really:)) disconnected, daemon threads as a concept. I was told it is very useful programming tool. I can not decide for myself -- never used it.

Now for the arguments. For the person who wrote "at least with pthreads, you aren't confined to a win32 platform". Actually you are confined to pthreads platforms. I do not see the difference. Windows does have its own market share. And that market share does not support pthreads. Various open source ports are at least in order of magnitude slower then native on Windows.

The argument that it is difficult to design "...scheme that doesn't risk missed wakeups ..". To be honest with you I have the exact same filling about pthreads. I think it is just multithreaded programs are difficult on its own and when you do not have familiar tools, you have difficulty.

For the cost of handles and low-level vs. high level API. It is huge discussion on its own. Since nobody talked about switching between kernel and user mode I do not think it is in the scope. It also is difficult to judge since concept is somewhat abstract. I never thought of Windows threads API as high level , but argument could be made I guess that since we are not at kernel we are high level. I do not believe pthreads operate at kernel either so it is probably not low level too.

Currently I am writing portable servers. Over all performance is same on similar hardware Windows or Linux. There are slight differences in context switching and IO handling, number of threads and memory consumption, stack size etc., but over all the same application perform similarly.

I know it is a bad thing to do , but I also would like to mention that author of the article did not really had enough knowledge to compare 2 APIs

I hope my post adds to the discussion. Sorry for the spelling.

By Appunti Disordinati Di Viaggio on February 27th, 2007 at 10:19 am
Why Windows Threads Are Better Than POSIX Threads

By J. Graham on February 27th, 2007 at 1:19 pm
Weird post, odd response and if I may say so egregiously handled there Clay.

Lots has been said about PThreads/WinThreads I doubt there's much I would add to that discussion. It's interesting how the few folk who mention 'Ad hominem' attacks though.

Seemingly there are actually very few. There are plenty of people questioning your credibility. That isn't necessarily an 'ad hominem' attack - unless they are saying that your view on PThreads is false by virtue of your alleged lack of credibility. After all you can have zero cred and still be right. There are some people calling you a shill - again not an AH attack unless used as an argument and there is at least one person saying that you were irresponsible in posting stuff the way you did again a separate issue. In fact, just to get the point across to bloggers and anyone else who doesn't get it. If after reading your post the person in the next cube stood up and screamed in your face "Asssssshoooolllle!" that is also not an AH. After all you, in fact may BE an asshole and said post may, in fact be clear evidence of it.

Now you might be attempting to use the term in some silly sense e.g. "Anything that talks about the person (in negative terms)" however not only is that not the formal term it also has some consistency problems.

Sure you might want to argue that all those issues I describe above are beside the point you were trying to make but then again you are the one who chose the modality of your post (somewhat deceptive by my standards) and the response is pretty much what you get for the decision you made.

In short: Suck it up and read a book on formal logic.

By D. Lymper on February 28th, 2007 at 7:05 am
Apart from the flames raised by Clay's contradicting stories, as an impartial observer, having worked very little with threaded environments (but in both platforms), and having read the indeed informative post from AlexO above, I ask myself, WHY bother comparing pthreads and windows threads?
[devel point of view] - Is it crucial for choosing the platform of your app? No, if you like (or have to work with) linux/unix, you use pthreads either way; same goes for win.
[user point of view] Can you actually compare them in terms of performance/stability since they run on different platforms? Again, no, it becomes a totally different matter.
In each platform the programmer learns to use the tools provided. This whole discussion simply doesn't make a difference.
And about Clay: I have read all remarks on your post and know about your "laziness" to mention your older post. Then, why the title of this page is "Why Windows Threads Are Better Than POSIX threads", and not "Let's talk about Win and POSIX threads" (as you yourself say)?

By Programmazione.it on March 3rd, 2007 at 7:35 pm
Spesso si fanno dei paragoni tra Windows e Linux, più o meno sensati; questa volta nello specifico vi sono due opinioni diverse o "verita", ma sarebbe meglio dire punti di vista. Precisamente c'èchi affermache i thread di Windows sono migliori dei pthread usati in UNIX/Linux, e al contrario chi dice invece che sono migliori i thread POSIX. (continua...)

By Clay Breshears on March 5th, 2007 at 9:28 am
Seven days have passed, so it's likely safe to poke my head out to see if I'm going to get six more weeks of grief.

As was pointed out, this is really an "I Like XYZ Because..." article. Why not name it that way? Why go with such a final and conclusive sounding title? One word: passion. When Trekkies debate, they say "Picard is better than Kirk" or "Kirk is better than Picard". (Trekkers, of course, also consider Janeway, Sisco, and that one played by Scott Bakula.) There's no use of "Like" or "I think" or "I believe" in these pronouncements because they are passionate about their position. And three separate blogging experts/consultants have all told me that successful blogs are about demonstrating passion or no one will be interested in reading them.

I approach this whole multi-core revolution from the perspective of a programmer. I've been involved with parallel programming for some time, but only with "Big Iron" that either costs millions of dollars or is spread around a room with large-scale heat issues. So, it's cool that we now have multiple cores that can bring the parallel experience to the masses. My job is to be sure that the masses can program their applications to take advantage of the new processors today and in the future. When new supporting technologies are announced (for instance, transactional memory, 80-core processors, new parallel programming libraries), as a programmer, I look for those things that will actually be useful. For those useful technologies, I want to know what the simplest and most flexible way to take advantage to them will turn out to be.

As AlexO and D. Lymper have pointed out, a comparison of Windows Threads and POSIX Threads is a bit unfair since each is limited to a different operating system with little chance of crossover. Because of that, issues of performance between the two are specious to me. It's like comparing an automobile and a boat. A car may be more maneuverable and faster, but if you need to go from one island to another, you're sunk if you try to use your car. Sure, you can race the two against each other, but each will be running in it's native environment. Not quite an apples to apples comparison for me.

With my current postition in the Intel Software College, I've been in the somewhat unique position of having to develop training for both Windows and POSIX threads (because we know that both models will be in use on multi-core platforms). I've been able to implement the same algorithms and example programs with both and I've come to appreciate and prefer Windows threads, from a programmer's perspective. It's close, not like the differences between Pepsi vs. Coke, but more like Miss Universe vs. Miss America. In the former case, I think one tastes like it has been made with goat sputum; in the latter case, they're both beautiful and talented women, but I may prefer brunettes over blondes or opera singing over baton twirling.

I appreciate all of those folks that have expressed their own opinion about why they prefer one programming model over another. There is no one right answer and I don't expect to convert anyone, but we can all demonstarte our passion for the model of our choosing and the reasons we think it is better. When we start getting competing versions of parallel support for C++ or completely new parallel languages, we will have a more level playing field to compare features directly.

By Thread contro Thread » StormedBrains on March 8th, 2007 at 10:03 am
[...] sul blog si esprime a favore dei Thread di Windows, affermando che questi sono pià¹ comodi da usare in quanto à¨ [...]

By John Millican on March 8th, 2007 at 1:48 pm
cool

By Kevin English on April 2nd, 2007 at 6:08 am
Clay came so close to stating my preference for Window's handle model without quite stating it and then the arguments drifter away from the point. So:

The huge advantage to Microsoft's model is the fact the WaitForMultipleObjects can do exactly that. When writing really tricky code that is dealing in asyncronous I/O from files and sockets and one also has some queues for background processing ... coding this up in Windows is very easy. In the Unix model you have to either choose one object type over the other to wait for first or code up your own semaphore signalling mechanism that each of your components signals at the end of their processing. The Unix model gives one several more opportunities to code up a bug than the Microsoft model does.

In the Microsoft world, all Handles can be thought of a having the base class of Event. Microsoft had the advantage of hindsight when coding their API, so of course their API is slightly more evolved. They realized the need to abstract the concept of 'things one may wait for' at the OS level. I don't see how anyone worth their salt in software design can't see the advantage of this.

I have done systems level programming on RT-11, RSX-11/M, VAX VMS 1.0->5.0, Unix System V, BSD 4.x, SunOS, AIX, Linux and NT 3.5->today. When it comes to threads, async-I/O and mutexes in my mind the MS Windows API makes the most sense because it requires the least effort to accomplish the goal.

By fish on April 18th, 2007 at 4:08 pm
Kevin, you are exactly right. I also have been programming with both APIs for some time and I agree wholeheartedly with both you and Clay. The windows threading API is vastly superior to the POSIX API. I fail to understand how a competent programmer who has spent time with both APIs would not come to this same conclusion. If anyone wants to see one great reason why the POSIX API is inferior, look at the pthread_cond_wait man page.

By Thinking Parallel | A Blog on Parallel Programming and Concurrency by Michael Suess on May 24th, 2007 at 10:02 am
software network) there are many hidden gems about parallel programming / threading / Intel and concurrency. Unfortunately, he also appears to have stopped updating his blog - and of course there is always the POSIX vs. Windows threads disaster. Readthisarticle and the comments below if you want to know what I mean. Thats it for today, I hope you enjoyed the trip into my newsreader a little. Have I forgotten anything? Its not like there are many blogs about parallel programming available, so if I

By cppkid on May 24th, 2007 at 12:53 pm
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.

By AlexO on June 19th, 2007 at 4:56 am
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 Clive Darke on June 24th, 2007 at 8:29 am
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 Jim Chorn on August 6th, 2007 at 9:28 am
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 John Daniel on August 15th, 2007 at 7:11 pm
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 Jeff Sadowski on September 11th, 2007 at 2:08 pm
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 arnshea on October 14th, 2007 at 12:59 pm
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 arnshea on December 1st, 2007 at 11:33 am
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 alexf2000 on January 17th, 2008 at 12:55 pm
Windows have POSIX threads as well. It is called fibers.

By matteo on May 8th, 2008 at 6:24 am
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.

Why Windows Threads Are Better Than POSIX Threads

By Clay Breshears (Intel) (75 posts) on October 19, 2006 at 8:00 pm

Categories: MulticoreTags: p=np

Comments (71)

What do you think?

Categories: Multicore
Tags: p=np