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?"

quothe the poster

[TinBromide]

"or what has changed since the first article was written?"

Vista's release and a massive advertising campaign/increase in revinue for microsoft partners?

$Money$

[ArcherB]

So who is right (metaphorically speaking?), or what has changed since the first article was written?"

Who was paying for it.

Look at the dates, Dude.

[DelawareBoy]

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.

Not the first such arguement

[Anonymous Coward]

"Taste Great" "Less Filling"
"Fruity Pebbles" "Cocoa Pebbles"
"Chocolate" "Peanut Butter"
"Duck Season" "Rabbit Season"

Re:Yes, the real world is a complicated place.

[Ctrl-Z]

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.

You didn't read the two articles, did you?

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.

Re:win32 has 1 thing i want pthreads to have

[Steendor]

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?

WaitForMultipleObjects

[zindorsky]

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!

Re:Look at the dates, Dude.

[AKAImBatman]

I think you misunderstand. My suspicion stems from the author's motivations, not whether Microsoft is involved or not. His first post was made to a software forum, where it's unlikely he was compensated for it. His second post was made to a semi-official corporate "blog", which raises questions about if he's being paid or not. Being an author myself, I know that's it's incredibly easy to step over the lines of journalistic integrity in exchange for that few hundred dollars of pay.

The question is, did the author really change his mind, or is he writing the conclusions that he knows will net him an income? If it's the former, he really should have expanded his article to prevent this sort of issue. If it's the latter, then the author is untrustworthy and should no longer be paid to provide his opinion in any professionally written form.

Microsoft never enters into the equation here, save for the fact that some entities may have a monetary interest in promoting Microsoft Windows -OR- Linux. (There's money in both directions.) That being said, it is sad that this issue may never have come up if the order of the articles was reversed. Slashdot is very pro-Linux (something which I am ambivalent about), meaning that it would have likely been seen as a win rather than the questionable journalism it is.

Re:Eeew, threads.

[daVinci1980]

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.

Re:Look at the dates, Dude.

[ultranova]

This being Slashdot, anything that is remotely pro-Microsoft MUST be viewed with suspicion, even if the author of the article does not work for Microsoft. We can't let them Win. (No Pun Intended)

I certainly hope that someone who first claims that "Separate data types" make Pthreads superior to Win32 threads and then turns right around and claims that they in fact make Pthreads inferior to Win32 threads gets viewed with a certain amount of suspicion, on Slashdot as well as everywhere else.

Re:WaitForMultipleObjects

[swm]

Let's see if I remember how to do this...

mutex mx;
condition_variable cv;
int a, b, c, d;

----- one thread -----

lock(mx);
while (! (a || b || c || d)) wait(mx, cv);
unlock(mx);

----- another thread ------

lock(mx);
a = 1;
signal(cv);
unlock(mx);

----- another thread ------

lock(mx);
b = 1;
signal(cv);
unlock(mx);

Re:quothe the poster-What Has Changed

[Nom du Keyboard]

"or what has changed since the first article was written?"

What has likely changed is were the paycheck came from this week.

Re:Look at the dates, Dude.

[Dogtanian]

This being Slashdot, anything that is remotely pro-Microsoft MUST be viewed with suspicion, even if the author of the article does not work for Microsoft.

Yawn.... are you trolling, or stupid, or both? The post you replied to gave a pretty good justification for not taking *either* article at face value.

Regardless of which threading model is better, the articles are contridictory, yet written just 16 months apart, with large parts similar and the author failing to acknowledge, let alone explain, his change of mind. In that light, they smack of a lame and insincere attempt to get attention.

Re:PThreads is better

[MythoBeast]

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.

Re:Eeew, threads.

[Jonny_eh]

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.

Re:Eeew, threads.

[mrsbrisby]

On Windows, there is a much higher penalty associated with spawning a child process than on Unix. This makes using threads much more attractive - they are faster.

No, it doesn't mean threads are faster, it really just means Window's CreateProcess()+setjmp()+longjmp() slower and uglier than fork().

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".

I don't know why the Windows equivalent of fork() is slower than the Unix fork().

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).

... perhaps Unix fork() is efficient because it is frequently used and has therefore been optimised in various ways (e.g. memory is only copied if there is a write on Linux). Whereas on Windows, those optimisations are not necessary.

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()".

Re:Pthreads = Win32 threads?

[AmX]

Pascal?

Re:Pthreads = Win32 threads?

[Anonymous Coward]

Smalltalk, Pascal and Ada come to mind first. All use := for assignment

Re:From the obvious dept

[Anonymous Coward]

... and what if you are trying to write portable multi-platform code? pthreads is the obvious choice...


Ummm... did you mean to say Java Threads?

Re:win32 has 1 thing i want pthreads to have

[softcoder]

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.

Re:Look at the dates, Dude.

[Overly Critical Guy]

This being Slashdot, people like you don't read the article. If you had, you'd see that it's the very same article but with some terms flipped, thus the suspicion. I understand that you're trying to appear enlightened by accusing everyone of bias, but it only made you look foolish.

Re:quothe the poster

[Anonymous Coward]

This is one of those situations where I wonder if it is still plagiarism. They used their own words, something they are free to do, sure, but on the other hand, they didn't cite the original source, even though it is obviously derivative and self-contradictory. The fact it is their own work doesn't change the unacknowledged nature of the previous work. If it was merely re-using previous statements, fine. That's lazy. But to disagree with them is weird without some kind of acknowledgement of the fact.

If this was a scientific journal article, and the editor and reviewers did their job, they might not call it plagiarism, but they certainly would insist that the original work be cited properly, and that the complete change of opinion be specifically acknowledged.

Quoting yourself is fine. Silently hiding the fact that you completely disagree with your previous statements is sloppy. It's okay to change your mind, but usually you admit it.

And memory footprint is a red herring.

[Ayanami Rei]

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.

Re:PThreads is better

[Twylite]

From the great grandparent:

If you really want the Win32 model, it is easy enough to build it on top of PThreads

From me (the grandparent):

Cough. Bullshit. Cough. Read Porting of Win32 API WaitFor to Solaris Platform [sun.com] to get a clue.

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.

Re:Look at the dates, Dude.

[Xabraxas]

While that's very true, what if the "research" happens to be correct? Or at least fairly positive? Agreed, most research studies have uncertainty to them (correlation vs. causation to name only one), but even if Microsoft paid for X research, do you really think, say, that a group of GNU-affiliated University Professors would actually have an unbiased view when comparing, say, Open Office to Microsoft Office? Even though there is no money changing hands?

The problem isn't the outcome or who funded the research as much as it is about disclosure. It is perfectly ok to do your own studies and publish the favorable results but you have to disclose that you funded the study. Otherwise it is just dishonest. Even if Microsoft didn't specifically ask for favorable results the researchers have a financial incentive to produce good results for Microsoft so they can get paid again when Microsoft wants another study done.

Re:From the obvious dept

[scotch]

Java threads only work on one platfrom, the Java platform.

Re:quothe the poster

[Listen Up]

a better java than java, I say

Bullshit. I develop full-time in J2SE/J2EE and now C# (.NET 2.0/3.0) as well. If you are just some beginner/non-developer, writing slightly more complicated Hello World applications, then you are not going to see any real difference between Java or .NET or . When it comes to writing real applications, such as applications leveraging massive amounts of long running transactional processes, enterprise message queuing systems (the existing MS message queuing systems are a joke), almost any SOA application (.NET 3.0 is getting better), almost any distributed scalable enterprise applications, the ability to develop an enterprise software solution on Windows and deploy it to Solaris/Linux/etc. with zero code changes (Mono you say...Not even close), etc. etc. etc. .NET is still 10 years back. How about a .NET equivalent to EJB 3.0? Not even close. Sure, the syntax of C# is nice, like Java, which it should be because Microsoft copied %99.999 of the syntax directly from Java.

The features and functionality available in Java 6 are astounding and are aimed squarely at making J2SE on the desktop, making J2ME ubiquitous in mobile devices, as well as securely putting J2EE years ahead of it competition. Java 7 is looking to be even more exciting.

For everyone whose last memory of Java is 10 years ago, you need to look at it again. Aside from basic single platform desktop applications, .NET is where Java was 10 years ago. Hell, Visual Studio is not even written in .NET nor any major application at this point (Office? IIS? Anyone?). Any real .NET app servers? And they certainly aren't running these applications on Mono. When I see Office running natively on Mono on Linux or OS X, I might be more interested. So Microsoft added automatic memory management and a common language runtime (with the intent to allow the possibility of cross-platform development on paper) to its main development languages. Yay. That doesn't make .NET equal to Java.

All of the enterprise .NET developers at the company I work at as well as many of our clients are excited about .NET 2.0/3.0 web services because .NET is finally starting to get services that have been available in Java for years. That is the true point of .NET in the development world. People on Slashdot need to stop drinking the beginner/non-developer kool-aid.

Re:quothe the poster

[aybiss]

To be clear, C# is a language specification and so is definitively as cross-platform as you get, and the only part of .NET not well supported by Mono is Windows.Forms (and of course the various SDKs like DirectX).

My 2c - pThreads suck ass. There's nothing worse than looking at 1000 Java 'processes' on your JSP server and wondering which ones will die if you kill one. It also makes it hard for the OS to figure out that App X hasn't had any CPU time for over 500ms.

Re:Do either compare favorably to OS/2 threads? :-

[Richard Steiner]

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.

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.