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?

$Money$

[ArcherB]

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

Who was paying for it.

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