Re: Why Pthreads are better than Win32 threads - Page 2

ClayB · ‎05-13-2003

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.

Separate data types. In Pthreads, each object has its own data type while in Win32 threads there is a mix of handles and separate types. 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 and less apt to lead to confusion. On the other hand, because of the use of the same type for different objects, when a Win32 program uses WaitForSingleObject, it may not be readily apparent if 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 functionality. I've actually seen Win32 code that used an array to hold both thread and mutex handles, then wait on those handles and execute different code paths depending upon which handle was signaled first. Correct implementation, yes, but a tough nut to understand on a first reading. While Pthreads may have more functions defined (around 60) than Win32 threads (I counted close to 30 thumbing through a book on Win32 threads programming) Pthreads has a single function to create threads. If you include the C Runtime Library, there are three separate ways to do this for Win32 threads.

Persistence of signals. It is up to the programmer to ensure the proper switching of Win32 events from the signaled to unsignaled state. Part of this involves setting the attributes of the event correctly and resetting manual events. If either of these is not done (and I've been guilty of not properly initializing or resetting events many times), the application will not function as expected. Tracking down this error can be difficult even with debugging tools. Under Pthreads, signals to condition variables are either "caught" by waiting thread(s) or discarded. However, use of a well known coding structure at each access of a condition variable will ensure no signals are "lost" by threads that may not be waiting at the exact time of signaling.

These are just some of the reasons that I think Pthreads is a better threading API than Win32 threads. What do you think? Do you have other reasons to prefer Pthreads? Or do you think Win32 threads is the better threading method? I'd like to hear about your preferences.

gianenrico_c_ · ‎03-23-2007

I was typing an answer, but "clay" said the right things:

- better model
- better simmetry in creating and destroying
- more logical

I prefer in particular how win32 release & kill other threads.
on pthreads is a bit tricky cancelling / killing.

threads modellig based on HANDLES and objects are consistent with other parts of windows.

When a ported an app from win32 to OSX (unix) I got some problems as some functionalities about creating / destroiyng are trickier.

I DID not find an elegant way to start a pthread in SUSPENDED mode.. does it exist?

but is a classic problem: people that like "lowercase & underscore" style of programming never love "Hungarian" style.
it's a philosophical problem...

egoeht69 · ‎10-20-2008

Hello everybody.

We are working with mutexes and events in our project (Windows and Linux), and we need to define events with manual reset option, this is not a problem in Windows, but I have not found any way to do the same in Linux.

Is there any way to use manual reset events into Linux with pthreads?

Thanks in advance for your responses, I am really lost with this stuff, I have tried to find a solution, but Google does not give me any good solution.

fb251 · ‎10-20-2008

Quoting - egoeht69

We are working with mutexes and events in our project (Windows and Linux), and we need to define events with manual reset option, this is not a problem in Windows, but I have not found any way to do the same in Linux.

Is there any way to use manual reset events into Linux with pthreads?

Can you be more specific, or better, give us an example of what you intend to do? I have some trouble to imagine what could be precisely "events manual reset option". BTW, it would be better to create a new and specific forum topic instead of waking up an old one.

Best regards.

oss-rajuldev · ‎10-23-2008

Quoting - Clay Breshears (Intel)

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.

Separate data types. In Pthreads, each object has its own data type while in Win32 threads there is a mix of handles and separate types. 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 and less apt to lead to confusion. On the other hand, because of the use of the same type for different objects, when a Win32 program uses WaitForSingleObject, it may not be readily apparent if 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 functionality. I've actually seen Win32 code that used an array to hold both thread and mutex handles, then wait on those handles and execute different code paths depending upon which handle was signaled first. Correct implementation, yes, but a tough nut to understand on a first reading. While Pthreads may have more functions defined (around 60) than Win32 threads (I counted close to 30 thumbing through a book on Win32 threads programming) Pthreads has a single function to create threads. If you include the C Runtime Library, there are three separate ways to do this for Win32 threads.

Persistence of signals. It is up to the programmer to ensure the proper switching of Win32 events from the signaled to unsignaled state. Part of this involves setting the attributes of the event correctly and resetting manual events. If either of these is not done (and I've been guilty of not properly initializing or resetting events many times), the application will not function as expected. Tracking down this error can be difficult even with debugging tools. Under Pthreads, signals to condition variables are either "caught" by waiting thread(s) or discarded. However, use of a well known coding structure at each access of a condition variable will ensure no signals are "lost" by threads that may not be waiting at the exact time of signaling.

These are just some of the reasons that I think Pthreads is a better threading API than Win32 threads. What do you think? Do you have other reasons to prefer Pthreads? Or do you think Win32 threads is the better threading method? I'd like to hear about your preferences.

This is good thread...

DDd1 · ‎11-15-2008

Quoting - Clay Breshears (Intel)

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.

Separate data types. In Pthreads, each object has its own data type while in Win32 threads there is a mix of handles and separate types. 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 and less apt to lead to confusion. On the other hand, because of the use of the same type for different objects, when a Win32 program uses WaitForSingleObject, it may not be readily apparent if 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 functionality. I've actually seen Win32 code that used an array to hold both thread and mutex handles, then wait on those handles and execute different code paths depending upon which handle was signaled first. Correct implementation, yes, but a tough nut to understand on a first reading. While Pthreads may have more functions defined (around 60) than Win32 threads (I counted close to 30 thumbing through a book on Win32 threads programming) Pthreads has a single function to create threads. If you include the C Runtime Library, there are three separate ways to do this for Win32 threads.

Persistence of signals. It is up to the programmer to ensure the proper switching of Win32 events from the signaled to unsignaled state. Part of this involves setting the attributes of the event correctly and resetting manual events. If either of these is not done (and I've been guilty of not properly initializing or resetting events many times), the application will not function as expected. Tracking down this error can be difficult even with debugging tools. Under Pthreads, signals to condition variables are either "caught" by waiting thread(s) or discarded. However, use of a well known coding structure at each access of a condition variable will ensure no signals are "lost" by threads that may not be waiting at the exact time of signaling.

These are just some of the reasons that I think Pthreads is a better threading API than Win32 threads. What do you think? Do you have other reasons to prefer Pthreads? Or do you think Win32 threads is the better threading method? I'd like to hear about your preferences.

Personally and i only started working with threads in C++ a couple of weeks, they both suck. The syntax is unecessarilly complicated, and i thank MS that they came up with a decent threading model in C# that actually makes threading code easy to write and read. As far as C++ threading goes, all libraries are complex and somewhat of a dark art, with very little details that have to be taken into account. I hope that a more approachable solution comes up, in the mean time, i guess i will have to do like everybody else and use Pthreads, simply because programming is not only going multi-core, it's more and more going multi-platform, using APIs that are multi-platform is becoming more and more relevant.

Chris_M__Thomasson · ‎11-15-2008

Quoting - egoeht69

Hello everybody.

We are working with mutexes and events in our project (Windows and Linux), and we need to define events with manual reset option, this is not a problem in Windows, but I have not found any way to do the same in Linux.

Is there any way to use manual reset events into Linux with pthreads?

Thanks in advance for your responses, I am really lost with this stuff, I have tried to find a solution, but Google does not give me any good solution.

[cpp]You can try something like the following:
_____________________________________________________________________
[/cpp]

[cpp]#include 


struct manual_event {
  pthread_mutex_t mutex;
  pthread_cond_t cond;
  unsigned state; // 0 closed - 1 open
};


/* create/destroy/error-checking omitted for brevity */


static void 
manual_event_set(
 struct manual_event* const self
) {
  pthread_mutex_lock(&self->mutex);
  self->state = 1;
  pthread_mutex_unlock(&self->mutex);
  pthread_cond_broadcast(&self->cond);
}


static void 
manual_event_reset(
 struct manual_event* const self
) {
  pthread_mutex_lock(&self->mutex);
  self->state = 0;
  pthread_mutex_unlock(&self->mutex);
}


static void 
manual_event_wait(
 struct manual_event* const self
) {
  pthread_mutex_lock(&self->mutex);
  while (! self->state) {
    pthread_cond_wait(&self->cond, &self->mutex);
  }
  pthread_mutex_unlock(&self->mutex);
}[/cpp]

_____________________________________________________________________

This should mimic Windows manual-reset event functionality; minus the broken `PluseEvent()' function of course!

;^D

Chris_M__Thomasson · ‎11-15-2008

Quoting - egoeht69

Hello everybody.

We are working with mutexes and events in our project (Windows and Linux), and we need to define events with manual reset option, this is not a problem in Windows, but I have not found any way to do the same in Linux.

Is there any way to use manual reset events into Linux with pthreads?

Thanks in advance for your responses, I am really lost with this stuff, I have tried to find a solution, but Google does not give me any good solution.

If you really want `PluseEvent()', well, here is how it might look with PThreads:

________________________________________________________________________

[cpp]#include 


struct manual_event {
  pthread_mutex_t mutex;
  pthread_cond_t cond;
  pthread_cond_t pluse_cond;
  unsigned state; /* 0 closed - 1 open */
  unsigned waiters; /* = 0 */
  unsigned pulse; /* = 0 */
};


/* create/destroy/error-checking omitted for brevity */


static void 
manual_event_set(
 struct manual_event* const self
) {
  pthread_mutex_lock(&self->mutex);
  self->state = 1;
  pthread_mutex_unlock(&self->mutex);
  pthread_cond_broadcast(&self->cond);
}


static void 
manual_event_pulse(
 struct manual_event* const self
) {
  pthread_mutex_lock(&self->mutex);
  while (self->pulse) {
    pthread_cond_wait(&self->pluse_cond, &self->mutex);
  }
  if (self->waiters) {
    self->pulse = 1;
    self->state = 1;
    pthread_cond_broadcast(&self->cond);
    while (self->waiters) {
      pthread_cond_wait(&self->pluse_cond, &self->mutex);
    }
  } else {
    self->state = 0;
  }
  pthread_mutex_unlock(&self->mutex);
}


static void 
manual_event_reset(
 struct manual_event* const self
) {
  pthread_mutex_lock(&self->mutex);
  if (! self->pulse) {
    self->state = 0;
  }
  pthread_mutex_unlock(&self->mutex);
}


static void 
manual_event_wait(
 struct manual_event* const self
) {
  pthread_mutex_lock(&self->mutex);
  ++self->waiters;
  while (! self->state) {
    pthread_cond_wait(&self->cond, &self->mutex);
  }
  --self->waiters;
  if (! self->waiters && self->pulse) {
    self->pulse = 0;
    self->state = 0;
    pthread_cond_broadcast(&self->pluse_cond);
  }
  pthread_mutex_unlock(&self->mutex);
}[/cpp]

________________________________________________________________________

That should do it...

Alexey-Kukanov · ‎11-17-2008

Quoting - DDd

Personally and i only started working with threads in C++ a couple of weeks, they both suck. The syntax is unecessarilly complicated, and i thank MS that they came up with a decent threading model in C# that actually makes threading code easy to write and read. As far as C++ threading goes, all libraries are complex and somewhat of a dark art, with very little details that have to be taken into account. I hope that a more approachable solution comes up, in the mean time, i guess i will have to do like everybody else and use Pthreads, simply because programming is not only going multi-core, it's more and more going multi-platform, using APIs that are multi-platform is becoming more and more relevant.

A little piece of ad :) - check Intel Threading Building Blocks, it might well be what you are looking for. OpenMP might also work well in many cases, and GCC supports it now as well as MSVC, so availability should not be an issue.

DDd1 · ‎11-17-2008

Quoting - Alexey Kukanov (Intel)

A little piece of ad :) - check Intel Threading Building Blocks, it might well be what you are looking for. OpenMP might also work well in many cases, and GCC supports it now as well as MSVC, so availability should not be an issue.

Thank for the tip Alexey. I will, TBB appears to be very useful for many tasks, and the built-in scalability is a very interesting feature. I am just learning the basics first, so i can understand what is going on behind the scenes in TBB, and have a better understanding of threading and multi-core architectures in general.

I am using The Art of multi-processor programming, the TBB book, and Wrox's Professional Multicore programming as guides. I am also writing allot of code, because programming is about doing and not reading (IMHO). I want to thank Intel for finally releasing the Nehalem platform for the general public, it will be a very interesting platform to build on top of, with 8 HW cores, things finally get interesting.

I certainlly hope that by this time next year we will have the Larabee platform to play with. It's very pleasing to see the Intel of the past 5 years, this is the Intel that made me fall in-love with programming in the early 90's on my dad's 386. Great Products, Tools and Support.

DDd1 · ‎11-17-2008

P.S: How do i get in touch with Dr. Clay? Too bad there isn't PM on these forums. I posted a question on your video tutorial, and if you have time i would appreciate a confirmation of my doubt. Thanks!

AaronTersteeg · ‎11-17-2008

Quoting - DDd

P.S: How do i get in touch with Dr. Clay? Too bad there isn't PM on these forums. I posted a question on your video tutorial, and if you have time i would appreciate a confirmation of my doubt. Thanks!

Dr. Clay is out of the office onSabbaticaltill Mid December. Let me look into the question and see if I could get someone else to jump in and answer.

Dmitry_Vyukov · ‎11-17-2008

Quoting - DDd

P.S: How do i get in touch with Dr. Clay? Too bad there isn't PM on these forums. I posted a question on your video tutorial, and if you have time i would appreciate a confirmation of my doubt. Thanks!

Go to your Profile -> Messages -> Create New.

But unfortunately there is no email notifications about new incoming private messages now...

Dmitry_Vyukov · ‎11-25-2008

Quoting - Clay Breshears (Intel)

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.

Separate data types.
Unambiguous functionality.
Persistence of signals.

These are just some of the reasons that I think Pthreads is a better threading API than Win32 threads. What do you think? Do you have other reasons to prefer Pthreads? Or do you think Win32 threads is the better threading method? I'd like to hear about your preferences.

I am not sure whether it makes sense to revive this thread now... Anyway most part of my thoughts was not relevant when Clay was starting the thread. But I can't not come to defense of my favorite threading model - Win32 threads.

I am not much concerned with things like "elegance" and number of data types and number functions. Anyway threading and synchronization must not be spread all over the application, it must be concentrated in some special low-level subsystem. As multi-threaded programmer in the multi-core era I am concerned mainly with *functionality* that API provides.

Win32 API developed vastly since appearance of multi-core processors (Windows Server 2003 and Vista). While pthreads is not changed very much. Here is some of the interesting Win32 threading API: SetThreadIdealProcessor(), GetCurrentProcessorNumber() (there is similar patches for Linux), SignalObjectAndWait(), FlushProcessWriteBuffers(), Thread Pool API, GetLogicalProcessorInformation(), SleepConditionVariableSRW(), lock-free list API, atomic RMW functions, etc.

The only serious thing I am aware of which is presented in pthreads, but is not presented in Win32 API is signals. And signals are very powerful technique. APC is similar to singals to some degree, but to use APC thread must wait in alertable state, this is not a problem in some applications, but serious problem for libraries, because they can't rely on application to wait in alertable state.