Slashdot Mirror

← Back to Stories (view on slashdot.org)

Pthreads vs Win32 threads

Posted by ryuzaki0 on from the different-situations,-different-needs dept.

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

25 of 385 comments (clear)

  1. Eeew, threads. by vadim_t · · Score: 2, Informative

    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.

    1. Re:Eeew, threads. by Cheesey · · Score: 3, Informative

      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.

      --
      >north
      You're an immobile computer, remember?
    2. Re:Eeew, threads. by pthisis · · Score: 2, Informative

      Windows does have a copy-on-write process creation mechanism--use ZwCreateProcess or NtCreateProcess with a NULL SectionHandle. It wasn't in Win98 and earlier, and it's poorly documented, which means a lot of Windows programmers don't use it and threads get massively overused.

      But threads are rarely the right choice; OS developers spent years implementing protected memory for good reasons, and throwing it out even within the bounds of one process is rarely beneficial. If you need to share a ton of complex data structures that can't easily be allocated in shared memory, then threads are worthy of consideration; in practically every other case, multiple process solutions will wind up being easier to implement and maintain, and more stable.

      Threads look seductively easy at the outset, but you actually have to do a lot of bean counting to get things right; with multiple processes, you have to explicitly set up IPC which makes it _look_ more complex but in reality makes it very clear what the shared resources are. Finding any synchronization problems usually winds up being a lot easier in multiple process systems, and there are the obvious stability and security benefits.

      And depending on the task, multiple process solutions may actually be faster since when 2 process are running on seperate CPUs there's no need to worry about cache coherency, etc between them unless they're actually hitting shared resources.

      But the performance differences tend to be negligible in practice for many applications; benchmark and see before assuming.

      --
      rage, rage against the dying of the light
    3. Re:Eeew, threads. by Kashif+Shaikh · · Score: 3, Informative

      You had no issues because a) performance was good enough and b) the rate of incoming client requests was relatively small compared to a loaded webserver. Now if you had thousands of client requests-per-second, the fork will show why-you-should-not-use-it-in-such-situations. In such cases you can use a pool of forked processes or simply write the whole damn thing using threads. For example, apache gives you the ability to change 'worker' modules...and you can experiment with that to get an idea of all these request processors. btw, threads don't complicate your code as long as you minimize data-sharing between threads and write the thread the same way as you were writing a forked process, except that you put all global variables within the thread's local data area. Kashif

    4. Re:Eeew, threads. by pthisis · · Score: 4, Informative

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


      I already got modded down for mentioning it elsethread (not sure why), but Windows does have ZwCreateProcess and NtCreateProcess. Both of those will do a copy-on-write fork() style process creation if you pass them a NULL SectionHandle--it is much more efficient than the normal CreateProcessEx and is the way to go for doing heavy multiprocess stuff on Win32.

      see, e.g., http://www.osronline.com/showThread.cfm?link=35916
      --
      rage, rage against the dying of the light
  2. win32 has 1 thing i want pthreads to have by musikit · · Score: 2, Informative

    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.

    1. Re:win32 has 1 thing i want pthreads to have by tjw · · Score: 4, Informative


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

      --

      XJS*C4JDBQADN1.NSBN3*2IDNEN*GTUBE-STANDARD-ANTI-UB E-TEST-EMAIL*C.34X
    2. Re:win32 has 1 thing i want pthreads to have by dominator · · Score: 4, Informative

      pthread_cond_timedwait() waits on a condition variable, which basically signals that a mutex has been released. Win32 calls these things "events". It is not the same thing as joining on a thread. Joining a thread means "I'm waiting for this thread to exit, so that I can capture its return value."

      Sure, you could implement something like pthread_join_with_timeout() using a conditional inside the thread. But you'd need to do that manually, as pthreads doesn't provide a primitive for that particular use-case AFAIK.

    3. Re:win32 has 1 thing i want pthreads to have by boa · · Score: 3, Informative

      >Sure, you could implement something like pthread_join_with_timeout() using a conditional inside the thread. But you'd need to do that manually, as
      > pthreads doesn't provide a primitive for that particular use-case AFAIK.

      A quick look in pthread.h tells me that there's one function named pthread_timedjoin_np. The function seems to be a GNU extension and the _np suffix is short for not portable. It probably does that the OP wants, but may not be portable enough for his needs.

      HTH
      boa

  3. Re:Look at the dates, Dude. by Anonymous Coward · · Score: 5, Informative

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

  4. PThreads is better by swm · · Score: 4, Informative

    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.

    1. Re:PThreads is better by leuk_he · · Score: 4, Informative

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

    2. Re:PThreads is better by PhrostyMcByte · · Score: 5, Informative

      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.

    3. Re:PThreads is better by dmayle · · Score: 2, Informative

      As my comment is mounting in score, I just realized that I said negative mutexes when I meant negative semaphores. Of course you can't have a negative mutex, a mutex is just for mutual exclusion. It's a semaphore that has a count associated with it.

      Sorry for the typo...

    4. Re:PThreads is better by gooser23 · · Score: 2, Informative

      You may not be able to use sockets directly with WaitFor[Single|Multiple]Objects(s), but you can attach an event to a socket (using WSAEventSelect IIRC) and wait on that, along with other things (which effectively gives you BSD's select() for Windows' file handles.

      As far as the discussion on concurrent programming goes, I'm surprised no one has yet mentioned boost.threads.

      --
      "Dying tickles!" -- Ralph Wiggum
  5. Both and Neither by FellowConspirator · · Score: 1, Informative

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

  6. Is this a joke ? by CmdrGravy · · Score: 3, Informative

    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.

  7. A better Win32/Linux thread article by NullProg · · Score: 4, Informative

    It sounds like the developer from Intel needs to ask IBM:

    http://www-128.ibm.com/developerworks/linux/librar y/l-ipc2lin1.html

    Enjoy,

    --
    It's just the normal noises in here.
  8. Re:quothe the poster by ThePhilips · · Score: 3, Informative

    I can only hope that's funny.

    This is [censored] reality. Nobody program for Windows because he likes to program for Windows: people do that mainly for money. "Work" they say.

    Whatever you appear to like in competing implementations is irrelevant: M$ and corporate decision makers leaves you no choice.

    And there are really only two choices: (1) you go insane and start loving whatever management tells you to love or (2) you search for another job. Since the guy is with Intel, he's likely to have good payroll and option (2) doesn't ring any bells.

    [ I hope you have noticed that "I love POSIX" post is from year 2003 - and "I love Windows" from 2006. But honestly it all looks more like joke. ]

    I'd say from personal experience, that threading in Windows is total mess. POSIX threads might look limiting - but on other side you need to resort to threads in *nix ... well you do not have to resort to threads all. It is your own programmer's choosing: to use threads or to use state machines and async I/O. Under Windows bugs plagued/plague/will plague async I/O and programmers have no choice other then to use threads for sockets and file I/O. So under Windows you use threads for everything (except GUI which is restricted to "main thread"), while in *nix it is norm to see threads only in applications which want to take advantage of multi-processor systems for heavy computational tasks: math, code cracking, video encoding, etc. Heavy I/O tasks in *nix are all single threaded: Apache, Squid, MySQL, PostgreSQL, postfix/sendmail/exim, etc. (Though most now support optional multi-threading too - for really busy servers.)

    --
    All hope abandon ye who enter here.
  9. wdiff output by cortana · · Score: 3, Informative

    Why [-Pthreads-] {+Windows Threads+} are better than [-Win32 threads-] {+POSIX Threads+}
    Clay Breshears
    [-2006-10-19-]
    {+2003-05-13+}

    I've used both POSIX threads (Pthreads) and [-Win32-] {+Windows+} threads [-APIs-] {+APIs,+} and I believe that [-Pthreads-] {+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 [-Pthreads.-] {+the Windows threads API. This is all from the perspective of multithreaded code developers or maintainers.+} Let me illustrate with a few examples.

    [-Separate-] {+Simplicity of+} data types. In Pthreads, each object has its own data type [-while-] {+(pthread_t, pthread_mutex_t, pthread_cond_t, etc.) while,+} in [-Win32 threads-] {+Windows threads,+} there is [-a mix of handles and separate types.-] {+pretty much just the one type: HANDLE.+} For Pthreads this means different functions are used for working with each object type. Reading and understanding Pthreads code written by someone else [-is straightforward-] {+can be straightforward. However, this does mean that the programmer must know the number, order,+} and [-less apt to lead to confusion.-] {+type of parameters for all the different functions.+} On the other hand, because of the use of the same type for different objects, [-when-] {+there is+} a [-Win32 program uses WaitForSingleObject, it may not-] {+Create* function for each different object and a corresponding Release* function for most.

    Perhaps the biggest advantage of a single object data type is that there is only the one function needed to make a thread block while waiting for an object: WaitForSingleObject. Thus, only one set of parameters needs to+} be {+known regardless of whether the code is waiting on a thread, a mutex, a semaphore, or an event. The related function, WaitForMultipleObjects, is just as simple to use and easily overcomes the problem of needing to wait for multiple thread terminations one function call at a time (pthread_join) that Pthreads requires. While some may say that using a single data type for many different objects can lead to confusion when used in WaitFor* calls, programmers should set the name of the handle such that it is+} readily apparent [-if-] {+whether+} the code is expecting a thread termination, an event to be signaled, or a mutex to be released. [-This also illustrates my next point.

    Unambiguous-] {+WaitForMultipleObjects+} functionality. [-I've-] {+Besides being able to block a thread waiting for multiple thread terminations in a single call, the programmer can+} actually [-seen Win32-] {+wait for any out of a set of threads to terminate. That is, even when only one thread has completed, the WaitForMultipleObjects function can be set to return and indicate which thread triggered the return. If there is specific "clean up" processing that depends on the identity of the thread that finished, this can be done before returning to wait on the remaining threads. This clean up processing will be done in the most efficient order possible, soon after each thread terminates, no matter in what order this happens. Pthreads can perform similar post-processing, but will need to wait for the threads to terminate is some fixed order. So, even if the last thread finishes first, it must wait for all the post-processing of the previous threads to be completed.

    Because different objects all use the HANDLE type, a call to WaitForMultipleObjects can be set to wait for any combination of threads, mutexes, semaphores, and/or events. This feature can give the programmer a flexibility that cannot be easily (if at all) duplicated in Pthreads. As an example, I've written Windows+} code that used an array to hold both thread and [-mutex handles, then wait on those-] {+event+} handles {+to support a threaded search through data. The ideas was to signal the blocking thread if the item being looked for was found+} and [-execute differen

  10. Re:quothe the poster by PitaBred · · Score: 5, Informative
    Did you notice the other similarities?

    Initial (2003) article:

    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 in the later article:

    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.
    It's not plagiarism because he copied from himself and just added a few edits, but c'mon... how lazy of a shill can you be?
    --
    My blog. Good stuff (when I remember to update it). Read it.
  11. Re:quothe the poster by PitaBred · · Score: 1, Informative

    ...civil disobedience is going against laws. I am fairly certain there was no governmental entity that told him to change his viewpoint on Windows threading.

    --
    My blog. Good stuff (when I remember to update it). Read it.
  12. He responded. by MythMoth · · Score: 3, Informative

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

    --
    --- These are not words: wierd, genious, rediculous
  13. Nothing has changed by einhverfr · · Score: 4, Informative

    Read the two articles closely, and side by side. What you will see is that both articles have an identical structure and make simply the opposite cases. The opening is almost verbatim between the two articles, for example.

    Although there are three year between the articles and people change, this looks to me like someone trying to write different articles from different viewpoints rather than proving that one is best. If he really had changed his mind, maybe he would have said so and referenced his previous article rather than copying it?

    --

    LedgerSMB: Open source Accounting/ERP
  14. Read beyond the first paragraph... by mattis_f · · Score: 2, Informative

    I was also fascinated by that ... but the articles actually diverge a bit later. The difference seems to be WaitForSingleObject in Win32 (in the older article, apparently it's not a good thing) which has been replaced by WaitForMultipleObject in the newer one (according to the author, a good thing).