Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Pthreads vs Win32 threads

Hemos posted more than 7 years ago | from the different-situations,-different-needs dept.

385

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

cancel ×

385 comments

Sorry! There are no comments related to the filter you selected.

quothe the poster (5, Insightful)

TinBromide (921574) | more than 7 years ago | (#18152856)

"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 (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18153204)

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

Nice try, Linucks-fanboi. Now go suck a greasy FOSS-cock, preferably your father's.

Re:quothe the poster (3, Funny)

Anonymous Coward | more than 7 years ago | (#18153366)

Get it right, assmuch. It's Linsucks or Linsux.

Vista is the coolest OS ever. OS X 10.4 is a total rip off of it.

Re:quothe the poster-What Has Changed (5, Insightful)

Nom du Keyboard (633989) | more than 7 years ago | (#18153594)

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

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

Vi (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#18152860)

What?

switch? (1, Interesting)

raffe (28595) | more than 7 years ago | (#18152868)

Looks like he just switched the words in the articles...?

Re:switch? (1)

elmaxxgt (980095) | more than 7 years ago | (#18152988)

indeed... at least he gave the same quality blogging for each party... or... something...

Re:switch? (1)

Anonymous Coward | more than 7 years ago | (#18152992)

Not quite, but I did leave a comment in his blog asking why.

http://softwareblogs.intel.com/2006/10/19/why-wind ows-threads-are-better-than-posix-threads/#comment -1284 [intel.com]

Re:switch? (2, Interesting)

Anonymous Coward | more than 7 years ago | (#18153138)

After reading both entries, I went to close the tab and was given a chance to provide feedback on intel's site. After clicking on all the survey questions, I left this comment:

Why not compare this (http://softwarecommunity.intel.com/ISN/Community/ en-US/forums/post/840096.aspx) with this (http://softwareblogs.intel.com/2006/10/19/why-win dows-threads-are-better-than-posix-threads/)

The WaitOnMultipleObjects() is the only diff, and latter the article is just a blatant recycling of the former; not very credible.

[tt]

Ninjas (0, Offtopic)

dunc78 (583090) | more than 7 years ago | (#18153020)

Reminds me of this ninja sight I came across a long time ago ( http://www.realultimatepower.net/index4.htm [realultimatepower.net] ). That guy had a corresponding sight for hippos I think that said the same thing except with Ninjas replaced by hippos.

$Money$ (4, Insightful)

ArcherB (796902) | more than 7 years ago | (#18152890)

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

Who was paying for it.

Re:$Money$ (1, Funny)

Anonymous Coward | more than 7 years ago | (#18153338)

I'm used to reading comments on slashdot, but this one confuses me -- what is smoneys?

different (1)

l3v1 (787564) | more than 7 years ago | (#18152892)

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.
 

Different people? (0)

Anonymous Coward | more than 7 years ago | (#18152904)

In this case wouldn't it be the same person having a different opinion on the same topic?

better yet (1)

popisdead (594564) | more than 7 years ago | (#18152918)

Who paid for the articles?

Re:better yet (2, Interesting)

DelawareBoy (757170) | more than 7 years ago | (#18152974)

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.

better yet-favourtism. (0)

Anonymous Coward | more than 7 years ago | (#18153102)

"Since Intel doesn't write operating systems, they really don't care which threading model succeeds."

They might change the processor to favour one over the other. And if memory serves, Intel use to do compilers?

Re:better yet-favourtism. (0)

Anonymous Coward | more than 7 years ago | (#18153524)

And if memory serves, Intel use to do compilers?

They still do.

Intel Compilers [intel.com]

Re:better yet (3, Funny)

burk3 (795975) | more than 7 years ago | (#18153334)

So one might say that intel goes both ways?

Pthreads = Win32 threads? (5, Funny)

arlo5724 (172574) | more than 7 years ago | (#18152920)

( Pthreads >= Win32 threads ) and ( Win32 threads >= Pthreads ) => Pthreads = Win32 threads

Re:Pthreads = Win32 threads? (0)

Anonymous Coward | more than 7 years ago | (#18153298)

( Pthreads >= Win32 threads ) and ( Win32 threads >= Pthreads ) => Pthreads = Win32 threads
more like:
( Pthreads > Win32 threads ) and ( Win32 threads > Pthreads ) => 0 (or FALSE)

Re:Pthreads = Win32 threads? (5, Funny)

anci_pants (518804) | more than 7 years ago | (#18153638)

I think you mean Pthreads == Win32 threads.

Although, it may be true that Win32 threads = Pthreads (which may account for the improvement)

Re:Pthreads = Win32 threads? (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18153658)

I think you mean Pthreads == Win32 threads.

Not everything uses == for equality and = for assignment, idiot.

Look at the dates, Dude. (3, Insightful)

DelawareBoy (757170) | more than 7 years ago | (#18152930)

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. (5, Informative)

Anonymous Coward | more than 7 years ago | (#18153010)

Except that the 2006 entry is essentially a structural copy of the 2003 entry, just with some wording changes. He even uses the same arguments against PThreads in the second entry that he used to support it in the first. Weird...

Re:Look at the dates, Dude. (5, Interesting)

AKAImBatman (238306) | more than 7 years ago | (#18153078)

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.

Normally I'd agree with you. But if you read both articles, you realize that his intentions may be a bit less honorable. The Win32 article is the exact same article, but with the conclusions changed. Maturing opinions usually result in some discussion of why one has changed their mind (even if it's only mentioned in passing) and/or a deep explanation of what caused their mind to change. This smells more like an attempt to play both sides.

Of course, it could be that the author is simply not comfortable with writing. He could be looking to make a quick buck by taking a simple forum post of his and modifying it to reflect his current opinion. It's worth giving him the benefit of the doubt on, but I am certainly suspicious.

Re:Look at the dates, Dude. (-1, Redundant)

DelawareBoy (757170) | more than 7 years ago | (#18153176)

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)

Re:Look at the dates, Dude. (0, Troll)

ajs318 (655362) | more than 7 years ago | (#18153376)

Look. Get this into your head:

Microsoft REALLY ARE that bad!

Re:Look at the dates, Dude. (4, Insightful)

AKAImBatman (238306) | more than 7 years ago | (#18153392)

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. (3, Insightful)

ultranova (717540) | more than 7 years ago | (#18153532)

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:Look at the dates, Dude. (2, Insightful)

Dogtanian (588974) | more than 7 years ago | (#18153596)

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.

And so the point becomes... (0)

Anonymous Coward | more than 7 years ago | (#18153328)

Who gives a shit. They're just threads, man. Both work.

It's even better if somebody _pays_ you to give an opinion on a matters of personal taste.

Re:Look at the dates, Dude. (1)

jimstapleton (999106) | more than 7 years ago | (#18153662)

NOTE: This quote is not the previous authors comment, but a modification.

Normally I'd agree with you. But if you read both articles, you realize that his intentions may be a bit more honorable. The Win32 article is the exact same layout, but with pieces of content and conclusion changed. Maturing opinions usually result in some discussion of why one has changed their mind (even if it's only mentioned in passing) and/or a deep explanation of what caused their mind to change. This smells more like he was embarrased about his old oppinions.

Of course, it could be that the author is simply not comfortable with writing. He could be looking to make a quick buck by taking a simple forum post of his and modifying it to reflect his current opinion. It's worth giving him the benefit of the doubt on, but I am certainly suspicious.
The content of this quote is exactly the same as the content of the parent like the content of the two articles are exactly the same.

There's a lot of different information in them, they just follow a very similar, and possibly copy and pasted format. Normally I would agree that a discussion of the change of veiw would be appropraite, and actually I still do agree, but your reply was a bit harsh. The two articles to me combine to say:

(1) pthreads are *MUCH* easier to learn for a novice programmer, and can get most tasks done just fine.
(2) Win32 threads are *MUCH* harder to learn [very believable after looking at some of the Windows API], but have a bit more functionality and flexibility.

It may also relate to a change in the Win32 thread API, but I doubt that would have changed so significantly.

Or you could be right, he could be a jerk out for a buck, but I doubt it's as clear-cut as your post suggests.

Of course, this being /. (0)

Anonymous Coward | more than 7 years ago | (#18153356)

We are going to get people who will post saying that the new article MUST be correct and then knock those that go against the OS choice. Worse, they get modded up like Soviet Union or Old person in Korea joke instead of the mod down that they rightully deserve. Hopefully,somebody else will look into the 2 postings and make some intelligent calls about them. Of course, I do not see how it can be intelligent when the exact same argument (in fact, same articles) are being used in a > b and b > a. It points out the author's illogic as well as the parent poster AND the modder of pp.

Re:Look at the dates, Dude. (1)

itsNothing (761293) | more than 7 years ago | (#18153608)

It is also true that Microsoft has paid to have "research" done which is more favorable to Microsoft products. Moreover, the "money trail" has often been brought to light AFTER the favorable research has had its first viewing by the public.

Microsoft has some of the best researchers money can buy. I wonder, sometimes, if this is more to keep them "off the market" than it is to use their knowledge. You know, buy your competition and muzzle them.

The articles were posted three yeats apart (0)

Anonymous Coward | more than 7 years ago | (#18152932)

Surely things could've changed the meantime?

From the obvious dept (5, Funny)

hey (83763) | more than 7 years ago | (#18152946)

If you are programming on Widows I would recommend Windows threads, while on *nix Pthreads are a better choice.

Re:From the obvious dept (0)

Anonymous Coward | more than 7 years ago | (#18153380)

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

What changed? The payor. (0)

Anonymous Coward | more than 7 years ago | (#18152962)

He wrote the articles for a fee, and the payor changed. Each payor had their own agenda.

Eeew, threads. (2, Informative)

vadim_t (324782) | more than 7 years ago | (#18152976)

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.

Re:Eeew, threads. (3, Informative)

Cheesey (70139) | more than 7 years ago | (#18153234)

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.

I don't know why the Windows equivalent of fork() is slower than the Unix fork(). Perhaps it is a historical thing. Unix programs often use fork() - shell scripts use it all the time (this is one reason why a Python or Perl script is often faster). I'm just guessing now, but 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.

Re:Eeew, threads. (2, Interesting)

multipartmixed (163409) | more than 7 years ago | (#18153616)

> (e.g. memory is only copied if there is a write on Linux)

Not just Linux.

I think this was the case with SVR4 and BSD4.3.

But that was a LONG time ago... memory gets fuzzy..

It's entirely probable that the first time I read about fork being copy-on-write was in Tannenbaum's yellow book, so it might even be in Minix.

It has certainly been the case as far as I'm aware in every non-toy Unix and UNIX for at least a decade.

But then again, I don't care, since I'm not a kernel developer. :)

Re:Eeew, threads. (4, Insightful)

daVinci1980 (73174) | more than 7 years ago | (#18153512)

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.

Win32thread vs PosixThread (1)

burni (930725) | more than 7 years ago | (#18152984)

Which one is better ?

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", ,you should have used Posix ;)

win32 has 1 thing i want pthreads to have (2, Informative)

musikit (716987) | more than 7 years ago | (#18153006)

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.

Re:win32 has 1 thing i want pthreads to have (2, Insightful)

Steendor (917855) | more than 7 years ago | (#18153246)

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?

Re:win32 has 1 thing i want pthreads to have (4, Informative)

tjw (27390) | more than 7 years ago | (#18153280)


I'm not an expert on pthreads by any means, but I think what you're looking for is pthread_cond_timedwait().

Re:win32 has 1 thing i want pthreads to have (1)

awol (98751) | more than 7 years ago | (#18153412)

Yeah, I know the feeling. We have an abstraction layer that does this goodness although even then not generically. The tradeoff in my view is true shared memory, and the pain that comes from the absence of that in Windows probably outweighs the goodness of WaitForSingleObject.

Interestingly, Linux has a call; semtimedop which works for semaphores

Not the first such arguement (1, Insightful)

Anonymous Coward | more than 7 years ago | (#18153014)

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

Re:Not the first such arguement (1)

ericski (20503) | more than 7 years ago | (#18153710)

Doesn't matter as long as it gets me drunk.
No to either.
Yes to both.
Duck Season. Definately Duck Season.

I see nothing wrong or contradictory here. (1)

mmell (832646) | more than 7 years ago | (#18153028)

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.

Wow! (-1, Redundant)

Ecuador (740021) | more than 7 years ago | (#18153030)

What an amazingly subtle sociological experiment! I for one bow to our mouse overlords and their complex socioanalytical probing! How brilliant! How subtle!

I bet (0)

Anonymous Coward | more than 7 years ago | (#18153044)

the anonymous reader who submitted story is the guy who posted both those pieces of opinions, you cant call those articles and he just switched some words.

anyway, quote from a comment there:
I have to say that I 100% fundamentally disagree with the major premise of your
comparison. POSIX threads are a low-level API and Windows threads are a
high-level API. Stating all the advantages of a high-level API while stating
none of the advantages of a low-level API just isn't fair.

why walking is better then driving (0)

Anonymous Coward | more than 7 years ago | (#18153082)

when you're inside a house?"

and "Why driving is better then walking when you're on the highway?"

are most certainly also good questions, eh submitter...?

In all sincerity I guess the man (justifiably) changed his opinion 3 years after writing the first article

An incentive .... (0, Redundant)

artgeeq (969931) | more than 7 years ago | (#18153084)

Maybe the author got a free laptop prior to the pro-Windows article.

PThreads is better (4, Informative)

swm (171547) | more than 7 years ago | (#18153086)

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.

Re:PThreads is better (4, Informative)

leuk_he (194174) | more than 7 years ago | (#18153252)

there is a pthreads [sourceware.org] implementation build on top if win32. I am not saying it is efficient, but it does the job.

Re:PThreads is better (2, Interesting)

complexmath (449417) | more than 7 years ago | (#18153258)

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.

Not strictly true. It is possible to build condition variables for Windows (Windows has Semaphores after all, which can be used to make just about anything), but the Windows threading model makes doing so far from easy. Please note that I'm not defending WinThreads, however, so much as clarifying this particular issue.

Re:PThreads is better (5, Informative)

PhrostyMcByte (589271) | more than 7 years ago | (#18153294)

You're in luck-

Vista comes with APIs for condition variables and reader-writer locks so you don't have to spend 15 minutes writing your own.

Re:PThreads is better (4, Insightful)

MythoBeast (54294) | more than 7 years ago | (#18153634)

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:PThreads is better (3, Interesting)

fitten (521191) | more than 7 years ago | (#18153324)

I've programmed in both and, other than the fact that you can't use sockets in the Wait... APIs (as you mention - but the BSD socket code is layered on top of native Win32, so you'd be passing objects created by two different subsystems to one subsystem's call, which shouldn't be expected to work), the rest of your post is either lack of experience with Win32 threads or subjective preference on your part.

Personally, I've found situations using each API where the functionality desired was very difficult to replicate in the other API. It usually requires some rethinking, is all. And, last I checked, there were things you could do in either API that weren't easily reproducable in the other API.

However, both APIs tend to evolve towards each other over time so it becomes less of an issue.

Win32 threads are better (1)

springbox (853816) | more than 7 years ago | (#18153458)

You can do the same things with both of them, but Win32 threads are less of a pain in the ass to work with.

Re:PThreads is better (1)

mitch0 (237776) | more than 7 years ago | (#18153582)

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.
This seems to imply that you can syncronize on condition variables and sockets at the same time. I've wrote some threaded server in pthreads some years ago, and I faced the same problem (I needed to wait on either a condition to happen or a socket selector to wake up) and I ended up using a socketpair() between the master and slave threads instead of a condition variable 'cos I couldn't wait on both at the same time. Has something changed in that regard, or I misunderstood you there?

thanks,
mitch

Re:PThreads is better (4, Interesting)

dmayle (200765) | more than 7 years ago | (#18153630)

It's not so cut and dry. I use a library I wrote to abstract away PThreads and Win32 Threads to give me a multi-platform interface, but I would say that each side has their upsides and downsides.

With pthreads, there's no way to combine socket i/o and thread notification. In Win32, I can have a thread waiting on both a socket and an event at the same time, allowing me to cleanly signal I/O blocked threads. This isn't the case with pthreads.

However, Win32 REALLY needs a way to handle negative mutexes (ie. taking more than one resource from a mutex at a time). I had to write my own, and it was a serious pain to make sure I didn't have any race conditions. All the articles I've seen on Win32 equivalents had race conditions, and that means that there means that there are probably developers trusting multi-threading primitives that they really shouldn't be./p>

Moo (-1, Redundant)

Chacham (981) | more than 7 years ago | (#18153090)

I think SCO should see where they get here complaining that "Clay Breshears" is not a real person.

Yes, the real world is a complicated place. (0)

mgblst (80109) | more than 7 years ago | (#18153098)

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.

Often you will find reasons to choose one thing, and other reasons to choose something else, life it tricky that way. When I was looking for a house, one was huge with lots of rooms, but out of town, and one was smaller, but so close to work.

Re:Yes, the real world is a complicated place. (5, Insightful)

Ctrl-Z (28806) | more than 7 years ago | (#18153212)

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:Yes, the real world is a complicated place. (1)

aled (228417) | more than 7 years ago | (#18153306)

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.

Often you will find reasons to choose one thing, and other reasons to choose something else, life it tricky that way. When I was looking for a house, one was huge with lots of rooms, but out of town, and one was smaller, but so close to work.


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

Bogus: In the end they are the same (0)

Anonymous Coward | more than 7 years ago | (#18153104)

I programmed with Threads in the following systems:

- Solaris SPARC
- Solaris Intel
- Linux Intel
- MacOSX PowerPC
- MacOSX Intel Dual Core
- Windows 2000 Intel
- Windows XP Intel
- Windows Vista Intel

with the following languages (threads implementations):
- C
- C++
- WxWdigets C++
- Java
- C#
- Obj-C

And the conclusion is that it depends how you program it and your system. In 1999 processes were actually faster than threads on Solaris SPARC. It also depends on the implementation of the Operating System/Processor. Solaris 7,8,9 etc have diferent implementations of PThreads. Windows too changes a lot, actually, what is Windows really??? With the constant updates, it is hard to say!!!

Both and Neither (1, Informative)

FellowConspirator (882908) | more than 7 years ago | (#18153122)

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

Re:Both and Neither (1)

cxbrx (737647) | more than 7 years ago | (#18153230)

Neither. See: "The Problem with Threads [berkeley.edu] ," Edward A. Lee, EECS Department, University of California, Berkeley, Technical Report No. UCB/EECS-2006-1, January 10, 2006.

Re:Both and Neither (0)

Anonymous Coward | more than 7 years ago | (#18153270)

Did you say "native"?
AFAIK, win32 is just a sub-system running on top of NT. In other word, win32 threads have peers that link down to NT ("sys") threads. So, there must be quite a bit of overhead when running win32.
Not so when running pthreads on top of Unices.

Point of view (1)

mcvos (645701) | more than 7 years ago | (#18153152)

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.

Re:Point of view (1)

geekoid (135745) | more than 7 years ago | (#18153352)

The articles in question are 3 years apart. Things change in 3 years.

Port? aha. I have had to write code that can be compiled in either enviroment.
Same code. Actually it had to cimpile in Solaris, Linux and Win32.

And when you don't know what's going on, STOP (1)

postbigbang (761081) | more than 7 years ago | (#18153462)

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.

"An anonymous reader"? (1)

kievit (303920) | more than 7 years ago | (#18153172)

I bet that "anonymous reader" is actually Clay Breshears himself.

Hmmmm... (0, Redundant)

Bastard of Subhumani (827601) | more than 7 years ago | (#18153184)

what has changed since the first article was written?
The author got a free (as in beer) laptop? [slashdot.org]

Overlooks the obvious... (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#18153196)

Win threads run on windows. Closed soure and proprietary. Score minus 50.

Posix threads run on GNU/Linux. Open source and free, as in freedom. Score plus 500.

These marginal performance issues are regularly addressed under the development of the Linux kernel. Meanwhile, Windows slaps on a new paint job, and tries to adapt all of their software to a more restrictive "security model" al-a, "Windows needs your permission...."

Simple Answer: (1)

sqlrob (173498) | more than 7 years ago | (#18153200)

What will net the most /. hits?

Re:Simple Answer: (1)

caluml (551744) | more than 7 years ago | (#18153552)

If thee casteth two opposing nets, thee will catcheth at least some fish.

- Me, 2007.

It's quite simple, really (3, Funny)

0xdeadbeef (28836) | more than 7 years ago | (#18153208)

One uses lowercase and underscores. The other uses studlycaps and Hungarian notation. It is an aesthetic choice.

Clone (1)

RAMMS+EIN (578166) | more than 7 years ago | (#18153214)

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.

there are differences, but not _that_ many (4, Interesting)

radarsat1 (786772) | more than 7 years ago | (#18153216)

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 a joke ? (3, Informative)

CmdrGravy (645153) | more than 7 years ago | (#18153222)

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.

Re:Is this a joke ? (1)

PseudoQuant (916182) | more than 7 years ago | (#18153666)

Haven't you heard? Due to the Energy Policy Act of 2005, April fools day has been moved 5 weeks earlier, with "mod following" conventions, putting it on the next valid business day. Today is officially "April fools day". Have at it!

This is the worst thread Ive ever read on Slashdot (0, Offtopic)

jofny (540291) | more than 7 years ago | (#18153236)

Im dumber for having read it. Thanks.

WaitForMultipleObjects (3, Insightful)

zindorsky (710179) | more than 7 years ago | (#18153272)

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:WaitForMultipleObjects (1)

Cheesey (70139) | more than 7 years ago | (#18153364)

Couldn't you use a semaphore for that? Get your producers to call sem_post when ready, and have your consumer call sem_wait. sem_wait will block until a producer calls sem_post. The relationship between calls to sem_post and calls to sem_wait is guaranteed to be 1:1.

Did I misunderstand what you were trying to do?

Re:WaitForMultipleObjects (2, Insightful)

swm (171547) | more than 7 years ago | (#18153536)

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:WaitForMultipleObjects (1)

zindorsky (710179) | more than 7 years ago | (#18153724)

This (and things like it other posters have pointed out) can work, and are what I usually end up doing when I program with pthreads.
But the downside is that you have to make all your threads do the signaling manually. You can't wait on arbitrary threads that do not have this functionality added to them. Whereas with the Win32 API, you don't have to remember to do that for every thread you create.

Theads vs processes (1)

Nicolay77 (258497) | more than 7 years ago | (#18153274)

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.

pthread is straightforward ? (1)

herve_masson (104332) | more than 7 years ago | (#18153288)

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.

God! Can Microsoft do *ANYTHING* right!?? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18153382)

How many ways can they screw things up?? Win32 threads are just stupid, stupid, stupid.

I like threads. (0)

geekoid (135745) | more than 7 years ago | (#18153444)

They really cut the wheat from the chaff when it come to programmers.

Watchig some hot shot contractor panic when you aask them to do threading is one of my favorite things. I always ask if the nderstand threading, they always say 'Yes' and only about 50% of them can actually do it.
The uderstand the definition of the verbage, but not implementation.

I should find him and ask him. (1)

lavid (1020121) | more than 7 years ago | (#18153482)

Looks like this guy lives in the "Chambana" area and probably attends/works at UIUC. I should find him and ask him!

Yeah, the 2k3 (pro pthreads article) is exactly the same as the 2k6 (pro win32 threads) except the cons in the first are the strengths in the second and visa versa. He doesn't really back any of this up with benchmarks, which would be impossible given he likes them both :-p.

Boring (1)

deblau (68023) | more than 7 years ago | (#18153508)

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 [wolfram.com] , you know.

win32 equivalent for pthread_cond_wait? (2, Interesting)

edwinolson (116413) | more than 7 years ago | (#18153550)

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?

Re:win32 equivalent for pthread_cond_wait? (1)

yeremein (678037) | more than 7 years ago | (#18153684)

What is the right way to do a pthread_cond_wait under win32?

Use the Boost Threads library [boost.org] . It's portable to many platforms (including Windows) and supports condition variables [boost.org] .

Obvious (0)

Anonymous Coward | more than 7 years ago | (#18153718)

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

He probably became aware that whores earn more than journalists.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?