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?
Looks like he just switched the words in the articles...?
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.
It's interesting when different people have different opinions.
Not so long ago, to some extent even today, there have been certain parts of this planet where that could have been called interesting indeed, but that only by some elements of their governments. Now, you calling that interesting makes an interesting picture of you.
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
In this case wouldn't it be the same person having a different opinion on the same topic?
( 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.
Surely things could've changed the meantime?
If you are programming on Widows I would recommend Windows threads, while on *nix Pthreads are a better choice.
He wrote the articles for a fee, and the payor changed. Each payor had their own agenda.
Both are on the Intel Website, so it would appear, if any $$$ was paid at all, it would have been Intel both times. Since Intel doesn't write operating systems, they really don't care which threading model succeeds.
Here's the one thing Windows needs: fork()
Threads have all sorts of nasty issues and pitfalls on any platform. Meanwhile, fork() is beautifully simple, and fork + socketpair lacks pretty much all of them. The speed may be a bit lower, but there's the great benefit of simpler and much safer code.
Which one is better ?
;)
,you should have used Posix ;)
Perhaps it´s the same discussion that language A is better than language B ?
perhaps it´s the same answer, the one that you prefer and fits your style.
You will find posix implementations on much more plattforms, so if you want to write portable
code, you should know you shouldn´t try win32thread
so if somebody of the operating Buzzwordfollowers heared "Linux" and now prays "Linux",
i have had to do a lot of porting from win32 to linux/bsd/mac lately and maybe i just cant find it in the documentation anywhere but 1 function i would really appreciate the pthread team adding is
pthread_join_with_timeout() the equivilent of the win32 WaitForSingleObject
often i set a flag for a thread to end and it might have already been completed. i want to be able to join immediately if it's already completed and if it isn't process some other event and try to join again.
i can program around this however it would be extremely nice addition to pthreads.
"Taste Great" "Less Filling"
"Fruity Pebbles" "Cocoa Pebbles"
"Chocolate" "Peanut Butter"
"Duck Season" "Rabbit Season"
Reminds me of this ninja sight I came across a long time ago ( http://www.realultimatepower.net/index4.htm ). That guy had a corresponding sight for hippos I think that said the same thing except with Ninjas replaced by hippos.
Aren't most *NIX users (and especially Perl-geeks) fond of saying that there's more than one way to get the job done? I'd say the only difference here is choosing the right tool for the right job.
the anonymous reader who submitted story is the guy who posted both those pieces of opinions, you cant call those articles and he just switched some words.
anyway, quote from a comment there:
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.
and "Why driving is better then walking when you're on the highway?"
are most certainly also good questions, eh submitter...?
In all sincerity I guess the man (justifiably) changed his opinion 3 years after writing the first article
Maybe the author got a free laptop prior to the pro-Windows article.
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.
It is perfectly feasable for there to be ways in which Win32 threads are better than Pthreads (as hard as that is to believe), and also vice versa. Hence the two articles.
Often you will find reasons to choose one thing, and other reasons to choose something else, life it tricky that way. When I was looking for a house, one was huge with lots of rooms, but out of town, and one was smaller, but so close to work.
"Since Intel doesn't write operating systems, they really don't care which threading model succeeds."
They might change the processor to favour one over the other. And if memory serves, Intel use to do compilers?
I programmed with Threads in the following systems:
- Solaris SPARC
- Solaris Intel
- Linux Intel
- MacOSX PowerPC
- MacOSX Intel Dual Core
- Windows 2000 Intel
- Windows XP Intel
- Windows Vista Intel
with the following languages (threads implementations):
- C
- C++
- WxWdigets C++
- Java
- C#
- Obj-C
And the conclusion is that it depends how you program it and your system. In 1999 processes were actually faster than threads on Solaris SPARC. It also depends on the implementation of the Operating System/Processor. Solaris 7,8,9 etc have diferent implementations of PThreads. Windows too changes a lot, actually, what is Windows really??? With the constant updates, it is hard to say!!!
It's not that difficult. POSIX' value is in its portability. Win32's value is in the fact that it's the native model.
Generally speaking, the native model will always offer superior performance and a superset of the features of POSIX threads. Be that Win32, Solaris, Linux, or what have you -- it's a good rule of thumb that the native threading model and API performs better and is more flexible.
That said, the difference is generally small enough that it's eclipsed by the portability feature if portability will ever be a concern. The fact that the programmer can learn a single threading API and use it anywhere means more flexibility in development and finding developers, and generally higher code quality (since people that have a skill focus on multi-threaded programming are almost assuredly well-versed in the POSIX API).
If you keep the two articles next to each other, you get a nice comparison of the advantages and disadvantages of each approach. Pthreads are apparently more elegant and easier to understand, but also more strict, while win32 threads are more lenient when you're not quite sure what's going on. In pthreads, there's only one way to start as new thread, in win32 there's more than one way. Undoubtedly each with its own advantages, but you do have to know the difference. As for persistence of signals, there's apparently two ways to do it, again each with its own advantages and disadvantages.
They both have one major disadvantage, though: They're different from the other, which undoubtedly makes it harder to port some code.
I bet that "anonymous reader" is actually Clay Breshears himself.
Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
What will net the most /. hits?
One uses lowercase and underscores. The other uses studlycaps and Hungarian notation. It is an aesthetic choice.
I don't know how win32 threads work, but I do know that I would like my thread system to have an interface like fork(), so both the original and the new thread continue from that point onward. This would unify threads with continuations, allowing interesting and powerful programming techniques. POSIX threads don't work that way, but Linux's clone() can, or so the manpage leads me to believe.
Please correct me if I got my facts wrong.
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.
Im dumber for having read it. Thanks.
Like the author, I have programmed with both pthreads and the Win32 threading API. I like the design of the pthreads API better, but (as the author also points out), pthreads has no equivalent to WaitForMultipleObjects. Sometimes it is very convenient to be able to wait on many objects and be able to be signaled by any one of them. With pthreads there is no way to do this.
Or am I missing something? Please someone, tell me how to wait on multiple objects (and be triggered by just one) with pthreads!
If the geiger counter does not click, the coffee, she is not thick.
AFAIR the windows theading model is better, because windows was designed with heavily multithreading in mind, and a very expensive operation of creation of new processes.
In Linux is the other way around: forking a process is very efficient, so no one used threads so they were not as efficient as the ones in Windows.
Of course both process creation in Windows and threading in Linux could have been perfected in all this years, but that is something I don't know.
That said, a bug in a thread will bring the application or server down, and a bug in a forked process is trivial to correct: just restart the process.
We are Turing O-Machines. The Oracle is out there.
Reading and understanding Pthreads code written by someone else is straightforward
I have to disagree with TFA. I think pthread is the most bloated API I have ever used; it is truly amazing how they managed to turn simplicity into messy useless complexity. Back in the dec/osf ages, my boss gave me a 300 pages book on pthread so that I could get started (there were not many examples at this time). This book was almost entirely dedicated to decypher this API, not even focusing much on multithread programming concepts. Even if you want to provide complex stuff (as pthread clearly does), you don't need to make every user paying the hard price, that's part of what a good API is, if you ask me.
Anyway, I think both are inadequate for direct use. I always write a small abstraction layer that fit my needs, and this layer is everything but concise on pthread, while it's quite small and elegant on windows. For once, windows API is properly designed, and that's rare enough to be said.
Who gives a shit. They're just threads, man. Both work.
It's even better if somebody _pays_ you to give an opinion on a matters of personal taste.
So one might say that intel goes both ways?
We are going to get people who will post saying that the new article MUST be correct and then knock those that go against the OS choice. Worse, they get modded up like Soviet Union or Old person in Korea joke instead of the mod down that they rightully deserve. Hopefully,somebody else will look into the 2 postings and make some intelligent calls about them. Of course, I do not see how it can be intelligent when the exact same argument (in fact, same articles) are being used in a > b and b > a. It points out the author's illogic as well as the parent poster AND the modder of pp.
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.
They really cut the wheat from the chaff when it come to programmers.
Watchig some hot shot contractor panic when you aask them to do threading is one of my favorite things. I always ask if the nderstand threading, they always say 'Yes' and only about 50% of them can actually do it.
The uderstand the definition of the verbage, but not implementation.
The Kruger Dunning explains most post on
You can do the same things with both of them, but Win32 threads are less of a pain in the ass to work with.
If you don't have a handle on the state machine, don't go further and hope that child processes through a fork or a thread spawn are going to inherit the conditions you want. This is a weak argument for spawning Win32 threads.
When compiling, the actions taken to get to assembler/machine code are far different between Win and Posix. Posix has a wonderful elegance and a brevity of code, but Win will take a much larger portion of the libs (depending on whose compiler you're using) to ensure it catches the state, which is inherently larger in Windows than most all *nixes. It might execute more cleanly (and there is no guarantee of this), but at the price of dragging enormous amounts of code with it. That extra code may also contain semaphores and constraints in unknown states, too, not to mention sensitive array boundary and cache management risks.
---- Teach Peace. It's Cheaper Than War.
Looks like this guy lives in the "Chambana" area and probably attends/works at UIUC. I should find him and ask him!
:-p.
Yeah, the 2k3 (pro pthreads article) is exactly the same as the 2k6 (pro win32 threads) except the cons in the first are the strengths in the second and visa versa. He doesn't really back any of this up with benchmarks, which would be impossible given he likes them both
If Bush wants to kill the terrorists, he should jump off a cliff.
Engineer discovers that there are pros and cons in deciding between two systems, but has to make a general value judgment. The world does not obey trichotomy, you know.
This post expresses my opinion, not that of my employer. And yes, IAAL.
I seem to recall looking for--and not finding-- a win32 equivalent of pthread's condition variables. E.g., atomically release a mutex and then wait for an event. As the (excellent) pthread man page describes, this is a useful operation, often necessary to avoid a race condition.
What is the right way to do a pthread_cond_wait under win32?
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."
"what has changed since the first article was written?"
He probably became aware that whores earn more than journalists.
...I'd stick with uC++: http://plg.uwaterloo.ca/~usystem/uC++.html
...or because it's mandated by work/school.
Use low-level constructs in low-level languages. If you're writing in a high-level language (like C++) you're doing so specifically to avoid things like pthreads.
not pretending to be very original, but:
1) Say something
2) wait
3) Say the opposite
4) not so "??"
5) Profit!
6) Sit and wait for the "get the facts" article based on 3)
I did not see a metaphor.
as a knock against Windows threads non-typed object HANDLEs, from article A:
"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."
in favor of Windows threads non-typed object HANDLEs, from article B:
"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."
Schizo much?
"It's interesting when different people have different opinions."
No it is not.
Except that Win32 threading model only works on X86 (since it needs Win32, which only runs on X86), while Pthreads work everywhere. Pthreads therefore mean more competition for Intel, since the program using them can be made portable.
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
hmmmm.... I dont know if its a case of MPD (Multiple personality disorder)
Windows has fork(), as well as all the other POSIX calls.
Originally, Windows NT had 4 separate APIs: the NT API, Win32, POSIX, and OS/2. The NT API was (and still is) the one used by the kernel. It has all the capabilities necessary to support the other three, and is never (well, rarely at least) used directly by applications. Win32 was, at the time, very new and hadn't seen wide use--it was designed as the primary API for Windows 95, and Microsoft wasn't yet sure whether it would catch on in the NT world.
The other two APIs have the same level of explicit support in the kernel as Win32, but there's a catch: you have to pick which subsystem you want to use for a given application. Win32 programs can't make calls to the POSIX subsystem, nor vice-versa. Over time, it became clear that only Win32 was being used for NT programming, and the other two APIs disappeared. The OS/2 API is, as far as I know, completely unavailable for modern versions of NT (i.e. 2000, XP, and Vista), while the POSIX API is still supported, but isn't available by default.
Check out Windows Services for Unix. This packages installs (and uses) the NT POSIX API.
For more information, read Microsoft Windows Internals
"With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea...."
RFC 1925
I have experience in both, and each one has it's strengths.
In one hand, Pthreads provides condition variables, wich can be used to build any synchronization primitive easily, but thread cancellation is brain-damaged: one has to choose if the thread can be terminated or interrupted, but not both. Also many calls cannot be timed out.
On the other hand, Windows threads provide high level synchronization objects, WaitForMultipleObjects and you can timeout waits, but those syncronization primitives are complex and easily lead to bugs, you have to be very careful.
I think an interesting point that no one is discussing is the fact that the 2003 "post" is from a community forum post while the 2006 "post" is formatted as a blog/technical article publication. Are we sure these are really the same people? Does Intel really have much to do with the 2003 forum post at all?
I have to agree with another poster that posited that this article's submitter is the same shill that wrote the blog entries.
You can be an atheist and still not want to succumb to some weird cross-over sheep disease -- AC
I ran both articles through diff and here's what it looks like: 1c1 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. 3c3 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. 5c5 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. 7c7 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. 9c9,15 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 conditio
One of the articles discusses "WaitForMultipleObjects" which seems to let me create multiple threads, and join them as they return or terminate.
I was trying to do something similar with pthreads and failed.
If in pthreads I want to create a thread pool, dispatch the threads to run as work comes in, how do I join the threads as they finish in easy to write manner?
]] in Windows threads, there is pretty much just the one type: HANDLE.
Yes. A HANDLE in WIN32 can also be a window, a file, a thread, a mutex, a pipe, a process and your grandmother. Since when is type checking not a good thing.
]] there is only the one function needed to make a thread block while waiting for an object: WaitForSingleObject.
Except, of course, if you're waiting for something to be posted to a pipe. Then you have to associate the pipe with a handle first. Oh and does he realize we have the same thing in UNIX ? It's called select() on a filedescriptor. Which you can't do in windows - because in windows, a pipe isn't a network socket isn't a filesystem object.
]] If a thread signals a condition variable and no other thread is waiting, does it make a sound?
Why do you want to write crappy code ?
Sorry - gotta go now. Diner's ready.
Not mentioned: Why does windows create recursive mutexes by default ?
Also not mentioned: Why doesn't UNIX have a proper POSIX event API that mixes with a threading API and a socket API ?
Religion is what happens when nature strikes and groupthink goes wrong.
Very true.
I think SCO should see where they get here complaining that "Clay Breshears" is not a real person.
Have you read my journal today?
Both Win32 threads and POSIX Threads provide a low-level API that are many people find confusing. I have written a "Generic Synchronization Policies" (GSP) library that provides a higher-level abstraction that is much easier to use and has been ported to several threading packaged (Win32, POSIX, DCE, Solaris). I do not claim that GSP is a silver bullet but it is a significant step in the right direction. Interested readers can find the software and documentation (HTML, PDF, PowerPoint) at my web site: http://www.ciaranmchale.com/. The software and documentation are released under an MIT-style license.
That the same guy would re-use his own words just goes to show you how useless most web article are. A witter is paid by the piece and will just bang out gibberish as long a he gets paid. I doubt these writers even have a real opinion. They are like lawers, they will argue either side. It's just a job.
In real life which is best depends on your goal. Do you want your code to be tied to Windows or do you want it to be portable to other platforms?
So what rights does this guy have? Can he sue himself for plagarism? I mean there's definitely prior art there.. Personally, I think he stands to gain from this blatant rip off of his previous work.
XenoPhage
Technological Musings
People who can't change their mind are called George Bushes and.. well look at the mess he got us into!
Only 'flamers' flame!
Does slashdot hate my posts?
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
> since it needs Win32, which only runs on X86
Didn't Microsoft do a wonderful job porting Linux to the XBox360?
This is a hoax. Read the FULL forum thread, not only the original post. Ho, wait...this is slashdot
"I was, of course, hoping to start some controversy and generate some discussion on the merits of both Pthreads and Win32 threads
-Clay"
There's a lot of languages out there, and the equals sign is a very popular symbol. In ML (which, like Lisp, is a functional language), '=' is used for both equality tests and assignment. On the procedural side, try Pascal (which used to be one of the most well-known languages). Equality is tested with '=' and assignment is indicated with ':='.
Gosh, and here I was thinking that Windows CE -- which uses the Win32 threading model more heavily than any of the desktop OS's -- ran on all those other processors...silly me. That ARM chip in my phone must really be an x86.
An interesting take on it from Brendan Eich:
0 07/02/threads_suck.html
http://weblogs.mozillazine.org/roadmap/archives/2
So my default answer to questions such as the one I got at last May's Ajax Experience, "When will you add threads to JavaScript?" is: "over your dead body!"
Sophistry has been around for thousands of years.
Here's a GREAT example of a multithreaded app... MySQL. Well done MySQL development team!!
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>--
http://users.actcom.co.il/~choo/lupg/tutorials/mul ti-thread/thread-pool-server.c
Create your thread pool, have it wait for events on a queue, pull off and process, loop. If handled_requests > threshold, optionally kill + restart thread. (Implementation of that last bit left as user excercise)
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Just curious. OS/2 software tended to be heavily thread-oriented even back in the early 1990's, and many programs had a half-dozen active threads or more. It seems like neither Windows nor Linux has that kind of history, which is why programs like Firefox still seem stupid (to me) about spinning off background tasks for things.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
The two posts simply take the same aspects for each, and reverse whether they're good or bad.
I haven't read through the comments, but there are plenty. With this success, I suspect the original poster is now trying the experiment on Slashdot.
I read both articles in their entirity. It just sounds to me like the author wrote the articles as a pair, flipping his arguments around from one article to the other, to make a point: that the differences between the two threading models are simply differences, and that it's easy to apply opposite value judgements to each of them just by changing the wording of your description of a difference (most obvious example is the paragraph on signal persistence; compare how he amplifies and dismisses the difficulty of the same coding practices in each article). Or perhaps he was trying to help strong partisans recognize the viewpoints of people they disagreed with and come up with new approaches to their programming problems, or maybe he was trying to encourage developers to improve each threading model by recognizing the strenghts of others.
To me that seems more likely than that he's a shill.
Seems to me that during the three years between the article he had a change of heart. I wonder if he is comparing old and slow linux pthreads instead of the newer nptl stuff in both cases?
because everyone has one.
Can someone explain why this is news, I mean other than the fact that the guy is a moron.
The implementation of threads on "UNIX" varies between BSD, unix, and Linux and each have their advantages/problems.
Window's threading model has its advantages and drawbacks.
Both threading systems spin off threads, and both platforms (assuming you can call UNIX a single platform) provide various mechanisms for synchronization and communication.
There is almost nothing you can do with one API that you can't do with the other. It is more your pre-existing preference for one methodology over another that would dictate your API preference.
I like pthreads better because I think there is a finer grain of control over how the thread executes.
"Computers are state machines. Threads are for people who can't program state machines." - Alan Cox
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
Windows:
pthreads:
This looks intentional to generate discussion. Does this "Clay" work for IBM? Is Clay trying to make the boards look active? Does Clay work for someone else? Is Clay trying to get someone else to do his/her (probably his, but i've learned not to assume) research?
Does Clay get -1 FlameBait for this?
As I understand it, Linux processes are lightweight enough that modern pthreads on Linux builds on top of fork/exec. Or something like that -- one is a wrapper for the other, I think.
In any case, reading through your suggestions, the only real difference is that if you're writing in C (and thus vulnerable to buffer overflows), segfaulting a process won't bring down the entire app. One other difference is that fork/exec would tend to be easy to make distributed, as most of your communication would be in pipes. However, both of these ultimately come down to how the app is written, not what language or API you're using.
So, the only real difference will be performance implications. On Windows, it's MUCH cheaper to spawn a thread than a process, and there is no fork, so on Windows, monolithic monstrosities are the only viable way to go.
Don't thank God, thank a doctor!
Because if a thread ever tries to take a mutex a second time while holding it once, this is probably the correct behavior. Maybe Microsoft just doesn't care if it is a little more expensive.
This is the weirdest thing. Two articles by the same guy with nearly identical text proving the complete opposite. Perhaps the author has a sense of humor and he's playing a big joke on us, and he really feels there is no significant advantage or disadvantage over one threading API or another.
The debate is pretty much irrelevant because you can't use Win32 threads on anything but Windows, and you can't use Pthreads on Win32 without problems. Different APIs for different domains.
Pthreads is portable, but only if your OS is very similar to Unix (MacOS X, Solaris, Linux, QNX). The less like Unix you are, the worse Pthreads will work (either in performance or reliability). Try Pthreads on Win32 or vxWorks, it doesn't work as well as the native APIs.
“Common sense is not so common.” — Voltaire
Unix sockets are excellent inter-process sync primitives. Coupled with the poll()/select() idiom you can create mailboxes for processes to send messages to each other, and depending on the OS implementation, you may get it with zero copies (or at most one), which is great.
You can use this in conjunction with shared memory when you don't want any copies to occur, or when you want to implement many-reader, single-writer.
And if that's not enough there's explicit POSIX IPC; not the greatest APIs but consistent in behavior across platforms. I mean it's good enough for Oracle...
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Zthreads? I'd heard they are nice and better than pthreads, I don't know about win32 threads.
What i know about win32 it's that process does not run, threads does.
How does that thing work in a GNU/Linux system?
"It's interesting when different people have different opinions."
No it isn't. Every person seems to have a different opinion about everything. Finding a person with a different opinion is about as interesting as finding out that there's porn on the internet.
"It's better to be a pirate then join the Navy"
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 Full reply here: http://softwareblogs.intel.com/2006/10/19/why-wind ows-threads-are-better-than-posix-threads/#comment -1322
n eed-another-parallel-programmi
My Selected Quote:
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-
ng-language/) 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.
I did win32 API coding at a previous job, at this one I use pthreads all the time.
The real difference isn't so much in the basic thread library but what you can do once you have the thread. There are a LOT of gotchas with standard unix library calls in a threaded environment. When you start digging you discover all kinds of uglies when mixed with the API's that existed before pthreads. Things as simple as open/close are stunningly broken on many unix'es when mixed with threads. Far to many things in the basic API assume a single thread. When mixed with signals, async IO, DIO etc your world quickly starts to fall apart and you loose cross platform portability, and end up abstracting things away to just the functionality you need. At that point you might just as well use whatever native API's exist with object wrappers.
Windows has its share of gotchas but the basic libraries work well with threads and provide everything you need without having to wonder how your going to get a thread safe version of getenv() (getenv_r() is not supported in glibc).
So how would you suggest generalizing orders from a government to orders from a corporation?
1) Write article about pthreads. /. anonymously.
2) Copy article, but change "pthreads" to "Win32 threads".
3) Submit articles to
4) ???
5) Profit!
(Sorry, I was really starting to miss the Underpants Gnomes jokes. Does a cliche become less so if it hasn't been used for a while?)
If you can read this sig, you're too close.
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
The answer, as usual is which one favors Linux, open source, Firefox and if none of the aforementioned fit, which ever one is less favorable for Microsoft.
addresses this.
:-)
The two articles mentioned in the summary are only identical in the first paragraph - then he starts talking about WaitForSingleObject (in the older article) and WaitForMultipleObject (in the newer one). He also mentions how to accomplish the same thing in pthreads. I think.
Didn't read it too closely, I was just looking for what the difference was.
I was also fascinated by that ... but the articles actually diverge a bit later. The difference seems to be WaitForSingleObject in Win32 (in the older article, apparently it's not a good thing) which has been replaced by WaitForMultipleObject in the newer one (according to the author, a good thing).
This is what Shrodinger's cat looks like before the waveform collapses, though once the superposition collapses, all statements made based on that superposition may collapse along with it.
I think the author just write on what's inside his mind, that's all. Except that might be the author have two personalities inside his mind? Let' see from both articles: A.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. B.In Pthreads, each object has its own data type while in Win32 threads there is a mix of handles and separate types. Which do you prefer? Pthread can be better than windows thread, windows thread can be better than Pthread. What's your great weakness? My great weakness is I don't have any weakness.
I believe what grandparent is referring to is cache synchronization.
In a multi threaded program, all memory is shared. Any change by one is immediately seen by the others.
In a fork()ed system, each process gets its own private copy. It modern systems, any page that hasn't changed is still shared, but writing to it produces a new, private, copy. (Copy on Write) Also, any new heap allocation is private and doesn't need to by synced with other threads.
On Windows, a context change is very expensive, and COW has historically been broken, but locks are very fast. Threads have a clear advantage.
On *nix, context change is about the same as thread change, and COW is well developed, but locks tend to be slower. Which is better depends on the task at hand. If your tasks don't need to talk to each other, such as in web servers, fork() tends to win out. If your tasks need to talk to each other a lot, such as database servers, threads win.
In a single processor environment, only one thread can run at a time, so synchronization issues are kept to a minimum. Hyperthreaded processors take this further in that two threads in the same process can run at the same time, but not from different processes.
In an SMP* environment, each processor has its own cache. This means any write to memory by any thread must be synchronized to the other processors (which may be running other threads in the same program) so they can stay in sync. This must happen, even if the memory written to is not actually used by any other thread. Also, any heap allocation or free that changes the page table must be synced to all threads in the same process. This can have a significant performance penalty, especially when many heap allocations are done. In a fork()ed environment, no such sync signals need to be sent, as all writes and allocates are private. The effect is even worse in NUMA systems.
*Note that Windows doesn't actually support SMP, in that threads from different processes can't be running at the same time on different processors, even if the hardware supports it. Only threads in the same process can be run at the same time. This again means that threading is your only option.
you seem to be somewhat misinformed. OS/2 and NT have pretty much the same heritage and hence why windows (NT) is VERY heavy into threads. The NT line has always been thread oriented and most programs use multiple threads. Yes there are plenty of badly implemented single threaded programs like Firefox as there were under OS/2 as well.
Certainly C# has some of the features java is missing. But it still lacks many important features needed for a "pleasurable" language. F# and nemerle may be pleasurable, but C# is like someone taking a cheese grater to your nads. And java is the same deal but with them pouring vinegar on afterwars.
Apache's threaded and forked worker models are virtually identical on unix. Their performance is the same, their memory usage is the same, the only issue is some modules don't work in threaded worker mode. The threaded mode was added for windows because using processes is slower on windows. On most unixes (like linux) threads are just shared space processes anyways, there is no difference in effeciency in the OS.
And of course, apache isn't even a good webserver for handling heavy loads. You want an event driven model like thttpd, lighttpd, zeus, etc.
as i said, n/t
Ah, thanks. I see now. The part about synchronizing caches between processors was what I needed to know.
With a little bit of additional investigative work (I clicked on the button that said "View Complete Thread" under the pthreads better than Win32 threads posting), I discovered a post that may shed some light on Mr. Breshears' change of heart:
It appears that a posting my someone called Joe Seigh may have given Mr. Breshears another perspective to consider. That he was willing to change his position, rather than stretch to justify an original stance, shows some character that often is missing from those who publically express a point of view. I would not be surprised if we saw Mr. Breshears arguing sometime in the future that pthreads are better than Win32 threads---perhaps after pthreads have come out with some innovations that make them even more effective.
Uh. No. Dave Cutler's rearchitected Windows NT kernel (from which all NT variants from 3.1 up to and including XP and probably also Vista are derived) has almost nothing in common with the 32-bit kernel that IBM completely rewrote for its OS/2 2.0 and later releases after the MS/IBM break-up.
In fact, it's probably closer to VAX/VMS than it is to OS/2.
Those two platforms' only common ancestry was the 16-bit OS/2 kernel, something both products shed 15+ years ago, and the only thing they had in common through NT 4 was the 16-bit VIO API that both of them supported (an old, outdated text-mode application interface even in the OS/2 world 15 years ago).
If you've ever done performance comparisons of OS/2 2.x versus any NT flavor of similar vintage, you'd be quite aware that OS/2 has historically washed the floor with its distant Windows cousin on similar hardware on both single- and multi-CPU configurations. Remember the NT Server versus Warp Server review where a single Warp 3 server outperformed NT Server on a quad-CPU machine in both file- and print-serving benchmarks? There's a reason for that. NT possesses a slow architecture by design, and that is true from the kernel outwards.
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
Well if Gort demands POSIX then we had better comply with the universal order.
Hey how many people think that Clay B and Clay Breshears are the same person who in 2003 was "totally" against Win32 and pro posix but has changed his mind so that in 2006 he flips his logic on it's head. Negatives have become positives now that Clay has three more years in the trenches under his belt.
What I first thought was that this article in fact isn't written by a journalist but an AI running on a quantum computer, so what we have here is a prime example of "superposition"!
Then I thought again about the journo and the paycheck, so perhaps what we have here is a prime example of "entanglement"...