This is the mail archive of the
mailing list for the pthreas-win32 project.
- To: 'Erik Hensema' <erik dot hensema at group2000 dot nl>, 'Pthreads-win32' <pthreads-win32 at sourceware dot cygnus dot com>
- Subject: RE: Performance
- From: "Bossom, John" <John dot Bossom at Cognos dot COM>
- Date: Wed, 22 Sep 1999 10:44:47 -0400
The pthreads-win32 library maps the pthreads interface and semantics
to the win32 threads interface.
The overhead depends upon what features of PThreads you are using. Many
features directly map to Win32 threads, whereas, others must be simulated.
For instance, mutexes can be mapped directly (and, in fact, the
library lets you choose to map to either CRITICAL_SECTION or kernel based
mutexes... CRITICAL_SECTION is about 100 times faster than kernel mutexes,
the expense of some functionality), whereas TSD keys that specify a destroy
routines requires simulation.
If you are using simple threading (create a thread) and simple use of
synchronization mechanisms (mutexes, semaphores) then the mapping to
win32 threads is straight forward.
If, however, you make extensive use of condition variables, and other
PThread features that do not exist on Win32, you will have to write
your own simulation code or change to use a different mechanism...
(or simply use pthreads-win32)
From: Erik Hensema [mailto:firstname.lastname@example.org]
Sent: Wednesday, September 22, 1999 10:29 AM
Sorry if this question has been asked before on this list, but the archives
seem te be offline.
I'm preparing to port a 110 kloc application from Unix to NT. It's very
performance critical, so we don't want to use API's like Nutcracker or
The application extensively uses multithreading, and we want to maximise the
performance. How does the pthread-win32 performance compare to the regular
win32 threads? And, if we aren't going to use pthreads-win32, how much
effort would it take to port our pthreads application to win32?
Erik Hensema, email@example.com