Slashdot Mirror
Pthreads vs Win32 threads
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 across an 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 article was written?"
So who is right (metaphorically speaking?), or what has changed since the first article was written?"
"or what has changed since the first article was written?"
Vista's release and a massive advertising campaign/increase in revinue for microsoft partners?
Is it sad that I am more likely to recognize you and your posts by your sig than your name or UID?
So who is right (metaphorically speaking?), or what has changed since the first article was written?"
Who was paying for it.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
( Pthreads >= Win32 threads ) and ( Win32 threads >= Pthreads ) => Pthreads = Win32 threads
The blog entry that points out the superiority of Win32 threads is dates to October 2006. The PThread example is a reply to a posting from 2003. I have a feeling that as the author worked more and more with the different threading models, he seems to have a more matured opinion. However, this being Slashdot, the Win32 Threading model is by definition inferior, since Microsoft has no intelligent engineers whatsoever and the author of the article was originally correct and should have never have looked further.
If you are programming on Widows I would recommend Windows threads, while on *nix Pthreads are a better choice.
The articles read like one of those English assignments where you have to pick an issue and then write two essays, one supporting each side. Probably the author wrote them to generate traffic to his websites, or maybe for freelance fees.
Anyway, PThreads is better. The reason is that Win32 gives you a fixed set of synchronization primitives. If you can solve your problem with those primitives. they work great. If you can't, you are completely stuck.
For example, it used to be that a socket handle was not a synchronization object, so you couldn't integrate select() calls with other synchronization primitives. Maybe that's been fixed, but if it isn't sockets, it will be something else.
PThreads gives you condition variables. They are harder to program, but once you understand them, you can use them to synchronize on absolutely anything. You aren't dependent on the OS to have foreseen your special needs and provided special synchronization primitives to meet them.
If you really want the Win32 model, it is easy enough to build it on top of PThreads, but there is no way to build PThreads on top of Win32.
The complaint about lost signals in PThreads means that the author is using them incorrectly.
One uses lowercase and underscores. The other uses studlycaps and Hungarian notation. It is an aesthetic choice.
From the first one: 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. And, from the second one: 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.
www.timcoleman.com is a total waste of your time. Never go there.
The thing is, they are just APIs. They both do just about the same thing. Asking which one is better is a pretty pointless question. I have always thought that the WaitFor* functions in Windows are quite nice, but frankly not that much of an advantage. It's quite rare that you actually need to wait for multiple objects of different types at the same time. Combine that with the fact that its semantics are slightly different for different objects (it destroys a thread, but only unlocks a mutex), and your program is that much more difficult to read. Of course, this is just comparing two APIs, a mostly pointless exercise, and says _nothing_ about implementation, which is quite a bit more important in terms of comparison. For example, Linux has completely changed its pthreads implementation since the switch from 2.4 to 2.6 (from LinuxThreads to NPTL), and programmers get the advantages without needing to change anything. In Windows, of course, we have no (or very little) idea of the implementation, except for what we can infer from the API, and performance tests. A third argument in this little debate could be to argue that one should just stay away from threads, period. I haven't successfully done it myself, since I find the threading paradigm useful, but using processes and non-blocking IO properly, one can avoid threads completely. Of course that's a bit easier to do with some of the Posix functions (eg. socketpair). But doing so will probably result in a more robust piece of software, and which scales better to multiple cores/processors. (Because processes do not share memory, so inter-thread cache misses will be minimized.)
That said, I find it quite creepy that this guy wrote these two articles with extremely similar wording for his introductions, making the exact opposite points. It is very strange. I wonder what his motivation was.
Is this some kind of weird joke ?
First of all on it's own terms the story makes no sense, the anonymous coward starts off by saying it's interesting when people disagree. He then links to two articles which, as he points out, are written by the same person and then asks who is right. He has just pointed out the opinions are both from the same person and he wants to know who is right, this is just moronic.
Secondly although I know nothing about PThreads or Win threads I can see that both those articles are largely the same with just the terms PThreads and Win threads switched so in one article he is claiming an advantage for one based on what he has stated as the advantages of the other in his other article.
Why is this on the front page, why was the submission accepted in the first place when it's complete nonsense and the most recent post by the author of both articles was in 2006.
On Windows, there is a much higher penalty associated with spawning a child process than on Unix. This makes using threads much more attractive - they are faster.
I don't know why the Windows equivalent of fork() is slower than the Unix fork(). Perhaps it is a historical thing. Unix programs often use fork() - shell scripts use it all the time (this is one reason why a Python or Perl script is often faster). I'm just guessing now, but perhaps Unix fork() is efficient because it is frequently used and has therefore been optimised in various ways (e.g. memory is only copied if there is a write on Linux). Whereas on Windows, those optimisations are not necessary.
>north
You're an immobile computer, remember?
I'm not an expert on pthreads by any means, but I think what you're looking for is pthread_cond_timedwait().
XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-U
So one might say that intel goes both ways?
It sounds like the developer from Intel needs to ask IBM:
r y/l-ipc2lin1.html
http://www-128.ibm.com/developerworks/linux/libra
Enjoy,
It's just the normal noises in here.
These solutions are not equivalent. And the reason that fork/exec doesn't have the same problems as threading is because it can only (realistically) solve a subset of the problems that multithreading can solve.
You have to consider the task you're working on before you decide whether you want to go with fork/exec or multiple threads.
A sibling post mentioned the cost of creating new processes on windows, and that's definitely something to consider: it's quite expensive to do so on windows.
However, the more important question is the problem you're working on solving.
If you're working on a task that allows each drone to work without communicating with any of the other drones, then fork/exec is a possible candidate. If you're working on an application where you require even a minimal amount of synchronization between different drones, fork/exec is a huge, huge pain in the ass.
An example of a good fork/exec app: webserver. One process deals with hearing the incoming connection, spawns off a new process to actually handle an individual connection. As a bonus, a single bad client connection will most likely NOT kill the whole webserver. (A malicious client will kill the process they've connected to, but probably none of the other processes, unless they manage to hang a database, etc).
An example of a good multithreaded app: anything that plays lots of sounds (for a specific example, a game). There's lots of synchronization that has to go on here: threads have to be started (or more likely pulled from a pool) to play a sound, the threads playing the sound have to check back periodically to see if they should stop playing (or need to adjust their volume or other processing effects), they need to notify the originating thread when they have completed, etc. No one in their right mind would use fork/exec for this. Besides the high overhead of the process spawn on windows, you would need a process for each of the sounds playing, and you would need to use the OS interprocess communication apis to synchronize between the different processes (shared memory, global mutexes, or file pipes). Note that file pipes aren't sufficient for synchronization, so you'd still have to use OS mutexes to sync on.
Yup.
I currently have no clever signature witicism to add here.
What has likely changed is were the paycheck came from this week.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
> Who gives a shit. They're just threads, man. Both work.
You know, I said this very same thing back in the 70s. However, my buddy with the bell bottoms and KISS shirt got more play than I ever did with my adidas shorts and Vader cape.
I hope, when they die, cartoon characters have to answer for their sins.
pthread_cond_timedwait() waits on a condition variable, which basically signals that a mutex has been released. Win32 calls these things "events". It is not the same thing as joining on a thread. Joining a thread means "I'm waiting for this thread to exit, so that I can capture its return value."
Sure, you could implement something like pthread_join_with_timeout() using a conditional inside the thread. But you'd need to do that manually, as pthreads doesn't provide a primitive for that particular use-case AFAIK.
Why [-Pthreads-] {+Windows Threads+} are better than [-Win32 threads-] {+POSIX Threads+}
Clay Breshears
[-2006-10-19-]
{+2003-05-13+}
I've used both POSIX threads (Pthreads) and [-Win32-] {+Windows+} threads [-APIs-] {+APIs,+} and I believe that [-Pthreads-] {+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 [-Pthreads.-] {+the Windows threads API. This is all from the perspective of multithreaded code developers or maintainers.+} Let me illustrate with a few examples.
[-Separate-] {+Simplicity of+} data types. In Pthreads, each object has its own data type [-while-] {+(pthread_t, pthread_mutex_t, pthread_cond_t, etc.) while,+} in [-Win32 threads-] {+Windows threads,+} there is [-a mix of handles and separate types.-] {+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 [-is straightforward-] {+can be straightforward. However, this does mean that the programmer must know the number, order,+} and [-less apt to lead to confusion.-] {+type of parameters for all the different functions.+} On the other hand, because of the use of the same type for different objects, [-when-] {+there is+} a [-Win32 program uses WaitForSingleObject, it may not-] {+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 [-if-] {+whether+} 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-] {+WaitForMultipleObjects+} functionality. [-I've-] {+Besides being able to block a thread waiting for multiple thread terminations in a single call, the programmer can+} actually [-seen Win32-] {+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 [-mutex handles, then wait on those-] {+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 [-execute differen
>Sure, you could implement something like pthread_join_with_timeout() using a conditional inside the thread. But you'd need to do that manually, as
> pthreads doesn't provide a primitive for that particular use-case AFAIK.
A quick look in pthread.h tells me that there's one function named pthread_timedjoin_np. The function seems to be a GNU extension and the _np suffix is short for not portable. It probably does that the OP wants, but may not be portable enough for his needs.
HTH
boa
A while back I had to write a server that would recieve concurrent network connections from different clients and then get some data from those clients and do some processing and then interact with a database, then when it's done the fork exits.
I ended up writing the whole thing using forks and no pthreads. My code was then subjected to a code review and one of the questions that came up in the review meeting was why I used fork and didn't do the implementation in pthreads. My arguement was one of complexity. I was challenged with the "fork is old technology, you should have used pthreads" and my response was "My implementation is easy to understand, oh and by the way, it works!"
Needless to say, my code has been in production for about a year and a half with no issues. I'm sure someone smarter than me could have wrote the whole using pthreads, but I'm just not sure what it would have gained them other than a slightly smaller memory footprint but at the price of increased complexity.
Yes Francis, the world has gone crazy.
We have always been at war with Pthreads. We have never been at war with Windows threads.
The submitter is clearly nuts. Everyone knows that we have always been at war with Windows threads. Anyone who suggests we're at war with Pthreads is insane.
--<Mike>--
Maybe it originated like that, but the fork/exec model of starting a new process has another really big benefit as compared to, say, Windows's CreateProcesses, which is that it's easier to control the execution environment of the child process.
Running as root and want to start the process with lower privileges? Do fork - setuid - exec. Want to open pipes to the child? Do pipe - fork - a couple calls in the child to connect the pipes to stdin/out - exec.
By contrast, Windows has to encapsulate anything you want to be able to do to set up the child's environment in the CreateProcess call. That's why it takes 9 arguments, one of which is a flags argument where there are 15 flags, and one of which is a pointer to a struct with 17 fields (one of which takes another 9 flags).
You had no issues because a) performance was good enough and b) the rate of incoming client requests was relatively small compared to a loaded webserver. Now if you had thousands of client requests-per-second, the fork will show why-you-should-not-use-it-in-such-situations. In such cases you can use a pool of forked processes or simply write the whole damn thing using threads. For example, apache gives you the ability to change 'worker' modules...and you can experiment with that to get an idea of all these request processors. btw, threads don't complicate your code as long as you minimize data-sharing between threads and write the thread the same way as you were writing a forked process, except that you put all global variables within the thread's local data area. Kashif
If you don't touch the heap, then not much is gained from pthreads over fork() in terms of memory usage. Code segments are shared, data is copy on write, and the stack is not shared in either case.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
I already got modded down for mentioning it elsethread (not sure why), but Windows does have ZwCreateProcess and NtCreateProcess. Both of those will do a copy-on-write fork() style process creation if you pass them a NULL SectionHandle--it is much more efficient than the normal CreateProcessEx and is the way to go for doing heavy multiprocess stuff on Win32.
see, e.g., http://www.osronline.com/showThread.cfm?link=3591
rage, rage against the dying of the light
http://softwareblogs.intel.com/2006/10/19/why-wind ows-threads-are-better-than-posix-threads/#comment -1322
--- These are not words: wierd, genious, rediculous
Read the two articles closely, and side by side. What you will see is that both articles have an identical structure and make simply the opposite cases. The opening is almost verbatim between the two articles, for example.
Although there are three year between the articles and people change, this looks to me like someone trying to write different articles from different viewpoints rather than proving that one is best. If he really had changed his mind, maybe he would have said so and referenced his previous article rather than copying it?
LedgerSMB: Open source Accounting/ERP