From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tristan Savatier To: Erik Hensema Cc: "'Pthreads-win32'" Subject: Re: [pthread-win32] Performance Date: Wed, 22 Sep 1999 16:17:00 -0000 Message-id: <37E96365.99DB2F3F@mpegtv.com> References: X-SW-Source: 1999/msg00096.html Erik Hensema wrote: > > 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 > Cygwin. > The application extensively uses multithreading, and we want to maximise the > performance. How does the pthread-win32 performance compare to the regular > win32 threads? very small overhead. we are also using pthread-win32 for a very cpu and thread intensive multimedia application. You can also look at the source code, and you will see that the pthread-win32 library does not do much processing. > And, if we aren't going to use pthreads-win32, how much > effort would it take to port our pthreads application to win32? it really depends on what your application does, and if it has to interact with the windows messaging API (e.g. WaitForMultipleEvents etc), which does not exist on unix. on unix, there are two distinct ways to synchronize tasks: using select to wait for data available on a pipe or socket, and using mutex and signal conditions. both systems are completely orthogonals and do not mix well, but sometimes unix applications have to use both, wich is possible but requires contortions and is not elegant. on win32, there is a unique way to synchronize, using events and messages. it is possible to wait until either an even or a message arrives. it simplify the design of win32 applications, but does not simplify porting from unix. There is some support for select on win32, but it does not work well and you cannot rely on it. for example, win32 select does not work with pipes and files. it seems to only work with sockets. -t > > Erik Hensema, erik.hensema@group2000.nl