Slashdot Mirror
Pthreads vs Win32 threads
An anonymous reader writes "It's interesting when different people have different opinions. While I was searching for something on Intel's website, I came across an article on why Windows threads are better than Posix threads. Curiously, I also came across this article on why Posix Pthreads are better that Win32 threads. The thing is, both of these articles are written by the same author!
So who is right (metaphorically speaking?), or what has changed since the first article was written?"
So who is right (metaphorically speaking?), or what has changed since the first article was written?"
"or what has changed since the first article was written?"
Vista's release and a massive advertising campaign/increase in revinue for microsoft partners?
Is it sad that I am more likely to recognize you and your posts by your sig than your name or UID?
So who is right (metaphorically speaking?), or what has changed since the first article was written?"
Who was paying for it.
There is no "I disagree" mod for a reason. Flamebait, Troll, and Overrated are not substitutes.
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.
"Taste Great" "Less Filling"
"Fruity Pebbles" "Cocoa Pebbles"
"Chocolate" "Peanut Butter"
"Duck Season" "Rabbit Season"
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.
Obviously it's not a required featuer, but perhaps it just wasn't deemed to be a useful feature.
The few times I've written multi-threaded programs, I had no reason to join completed threads at the earliest possible moment. One use I can think of would be to recycle threads to process a queue. In that case, wouldn't it be better to divide the recycling management and the processing into separate threads?
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.
These solutions are not equivalent. And the reason that fork/exec doesn't have the same problems as threading is because it can only (realistically) solve a subset of the problems that multithreading can solve.
You have to consider the task you're working on before you decide whether you want to go with fork/exec or multiple threads.
A sibling post mentioned the cost of creating new processes on windows, and that's definitely something to consider: it's quite expensive to do so on windows.
However, the more important question is the problem you're working on solving.
If you're working on a task that allows each drone to work without communicating with any of the other drones, then fork/exec is a possible candidate. If you're working on an application where you require even a minimal amount of synchronization between different drones, fork/exec is a huge, huge pain in the ass.
An example of a good fork/exec app: webserver. One process deals with hearing the incoming connection, spawns off a new process to actually handle an individual connection. As a bonus, a single bad client connection will most likely NOT kill the whole webserver. (A malicious client will kill the process they've connected to, but probably none of the other processes, unless they manage to hang a database, etc).
An example of a good multithreaded app: anything that plays lots of sounds (for a specific example, a game). There's lots of synchronization that has to go on here: threads have to be started (or more likely pulled from a pool) to play a sound, the threads playing the sound have to check back periodically to see if they should stop playing (or need to adjust their volume or other processing effects), they need to notify the originating thread when they have completed, etc. No one in their right mind would use fork/exec for this. Besides the high overhead of the process spawn on windows, you would need a process for each of the sounds playing, and you would need to use the OS interprocess communication apis to synchronize between the different processes (shared memory, global mutexes, or file pipes). Note that file pipes aren't sufficient for synchronization, so you'd still have to use OS mutexes to sync on.
Yup.
I currently have no clever signature witicism to add here.
What has likely changed is were the paycheck came from this week.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
Vista comes with APIs for condition variables and reader-writer locks so you don't have to spend 15 minutes writing your own.
Well, fifteen minutes writing, plus ten years of programming experience to be sure that you aren't going to create a deadlock in some obscure circumstance.
Wake up - the future is arriving faster than you think.
Just an FYI, fork isn't always available. The best example I can think of is uClinux, a linux distro for embedded computers. With an MMU, a process cannot be copied, therefore, only threads can be used. This can be a pain in the butt sometimes, but luckily pthreads aren't so bad once you know how to avoid races and deadlocks.
Windows threads and pthreads are functionally equivalent, and for some metrics in some circumstances, the actual implementations might be better at some tasks versus others. In general, a program written for pthreads ported to windows will be slower on windows for plenty enough other reasons, that it is difficult to say exactly which threaded system is "faster".Because Windows doesn't have an equivalent of fork(). It has a CreateProcessEx() which is like a fork()+exec() -- one of the common uses of fork, but by no means the only use (nor the one parent is talking about).No, it's that Windows developers think differently: Unix people think the Windows way of thinking is wrong. Windows developers think the Unix way of thinking is wrong (or "unnecessary").
fork() means data isn't shared. This means that you don't need complicated locking structures, semaphores, etc. This also means that you know what channels need auditing for security, and which channels need extending to increase parallelism (scale).
No matter how careful you are, threads never make auditing easier and they never make an application scale better (well, not significantly better).
This isn't to say threads don't solve some problems, it is to say that they don't solve the same problems as fork(), and I hope at this point it goes without saying that threads are not a "more efficient fork()".
Pascal?
Smalltalk, Pascal and Ada come to mind first. All use := for assignment
Ummm... did you mean to say Java Threads?
Not to disparage your legitimate concern. You are porting an existing app, and you would like analogous features in the target. However this is a bit like saying Linux will not be ready for the desktop until it can exactly emulate [fill in proprietary product here.] in spite of the fact that there may be equivalent but not identical capability provided.
Perhaps the development model for pThreads is different than the Windows one, and the call you want is not as useful if you are starting out from that model.
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
From the great grandparent:
From me (the grandparent):
It is not easy to build the Win32 model on Pthreads. The WaitForMultipleObjects emulation is a complete hack that pretty much re-implements the Win32 scheduler in userland. Even then it doesn't support a number of synchronization objects that Win32 can (e.g. threads, so that you can wait for thread termination). And it won't work properly unless the underlying *nix scheduler displays round-robin characteristics (anything with historical scheduling will cause a Producer-Consumer arrangement that works perfectly on Win32 to display massive latency on *nix).
The Solaris WaitFor described in that document works only with Event objects. You can't wait on anything other than events like you can in Win32, and you can't link Solaris file IO states (i.e. readable or writable) to those emulated events.
So you can't construct an instruction like "Wait for socket X to be readable OR event QUIT to be signalled", which is quite possible in Windows. In fact you can't do that at all on any *nix system that I am aware of (not even with kqueue or dev/poll to my knowledge). Instead you loop checking QUIT then doing a select()/poll() X with a timeout.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Java threads only work on one platfrom, the Java platform.
XML causes global warming.
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.