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

Comments

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?

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.

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

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

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.