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.
( 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.
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"
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 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'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.
What will net the most /. hits?
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.
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.
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.
This is Slashdot, post only binary answers to any questions or prepare yourself to flamed.
Example:
Question: what is the meaning of life?
Valid answers: true or false.
Mmmh... maybe nerds are programmed in Prolog
"I think this line is mostly filler"
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.
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.
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."
...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)
A lot senior programmers (myself included) run away from other people's threading code because there always seems to be one stupid, gotcha bug in whatever steaming pile of code we're handed that takes 168 hours longer than expected to find, and it's only found by old-school code-reading and note-taking, because the test case takes 12 hours to replacate.
Now, *writing* MT code from scratch without using local-to-the-enterprise libraries? Nobody with any skills should be afraid of that. If you can't visualize your threads interacting in your head... you don't fully understand the problem domain and should promptly commit seppuku.
Do daemons dream of electric sleep()?
> 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.
"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 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
Looking at the hot shot contractor's code after they blightly
forge ahead can be amusing as well.
I recall the work of a coworker in the multi-threaded realm,
he wrote a function to do something, and it needed a mutex
within it's bounds. That person locked very early in the
function, and held the lock for a long ( in clock cycles )
time. And that person had about 15 returns, each of which
very carefully released the lock. We kept having problems
which the log files kept telling us it was that function.
And every time, I would review that function for problems,
and aside from my dislike of the style, no problems would be
found. Then I told my boss I was tired of reviewing that
code each time this happened, I was going to rewrite it.
Minimized the time the lock was held, one in, and one out
( and got rid of several subblocks of code that were identical ).
No problems after that.
What is my point? Some can't do it. Fewer can do it. Of those
that can, not all do it well.
emt 377 emt 4
]] 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.
The problem isn't the change of opinion. The problem is the article is almost completely copy and pasted, as well as using the EXACT same reasons first why pthreads are better, and then in the newer one those reasons are why pthreads are worse. Now if the author pointed out his previous article (or just that he was originally a fan of pthreads) and explained why his opinion changed (such as what he learned between the 2 articles), THEN that would be an interesting read. But now both articles are just useless, since they use the exact same reasoning and logic, except with the opposite conclusion.
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
...when it come to programmers.
... ...
Watchig some hot shot contractor panic when you aask them... ask if the nderstand
The uderstand the definition...
Dde, did one f them write the nput hndler for you keeyboard? I don't thin it works so sht ho.
Schrodinger's cat is either dead or really pissed off...
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!"
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?
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.
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!
Maybe they were ninja hippos?
Oh come on, its 8am on a Tuesday, that's as good as its going to get aright?
...
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
Congratulations on making the first insightful+relevant post!
(To Slashdot, I mean. Not this article in particular.)
Seriously, though, thanks for pointing that out...
"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
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.
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.