pthreads works, sorta

Robert Collins
Mon Jun 25 17:30:00 GMT 2001

----- Original Message -----
From: "Greg Smith" <>
To: "Cygwin General MailList" <>
Sent: Tuesday, June 26, 2001 10:04 AM
Subject: pthreads works, sorta

> With Robert Collins' latest patches, the Cygwin pthreads
> as far as I can tell, seems functional (Thanks Rob!!).  However, its
> performance, in the words of an old friend of mine, `sucks dead bears'
> (he's a Hokie, which probably explains his phrasing ;-)
> My (heavily threaded) application runs approximately 100x slower than
> linux and proceeds to the point where the program thrashes because it
> calling pthreads functions faster than the pthreads implementation can
> deliver (we're talking _mutex_lock/unlock and _cond_wait/signal here).

Condition variables we can't do much about here, other than trying to
get down to the metal and rewrite em without OS support. I'm not keen to
try that, for what I hope are obvious reasons.

> I realize very well that in a development scenario functionality
> come first and performance second.  However, one of our developers is
> insisting on writing his own pthreads implementation for the
> (it's not really mine, I'm just a minor developer) on the Win32 side.
> As a programmer, I hate to see dual pathing based on platform in the
> hence this prod (er post).

Please, get your colleague to improve the cygwin pthreads code. That
will let him get his hands dirty, solve his problem, and prevent wastage

> I also know that Rob is fully aware of the performance problem and
> has ideas he wishes to implement, when he can spare some moments of
> valuable time.  However, as of 1.3, our application doesn't run on
> without kluging the threads implementation (by using a pthreads
> from ).  I am anxious to
> pthreads `right' on Cygwin.

I cannot read that implementation unfortunately - cygwin1.dll
contributes require copyright assignment. However if someone is
willing/able to give me relatively details english differences between
their mature implementation and the cygwin1.dll one, I'm more than happy
to recode what cygwin's got.

> I am willing to act as guinea pig or to contribute code myself.  Alas,
I am
> a procedural programmer and not an OOPer; although I understand the
> of classes, objects and methods, some of the syntax and methodolgy
> me.  However, ignorance has never stopped me from jumping in and
getting wet
> before.  I learned a long time ago that when you jump into water where
> don't know how deep it is, you don't jump in head first, and not feet
> but butt first (the reader is free to deduce any insights this analogy
> provides, if any ;-)

I don't OOP that well either :]. Give me asm and I'm happy :/.

The first step greg is to use Critical Sections instead of mutex's for
all non-process shared mutex's.

howto do that? Read up on win32 mutex's and win32 critical sections.
Then add a if (pshared) else clause to all the mutex member functions.


> Greg
> --
> Want to unsubscribe from this list?
> Check out:

Want to unsubscribe from this list?
Check out:

More information about the Cygwin mailing list