Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-ID: <03c701c0fdd7$82ddbde0$0200a8c0@lifelesswks>
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: "Greg Smith" <gsmith AT nc DOT rr DOT com>,
        "Cygwin General MailList" <cygwin AT cygwin DOT com>
References: <3B37D1A6 DOT 39A2685 AT nc DOT rr DOT com>
Subject: Re: pthreads works, sorta
Date: Tue, 26 Jun 2001 10:32:41 +1000
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-OriginalArrivalTime: 26 Jun 2001 00:20:59.0685 (UTC) FILETIME=[E0266D50:01C0FDD5]

----- Original Message -----
From: "Greg Smith" <gsmith AT nc DOT rr DOT com>
To: "Cygwin General MailList" <cygwin AT cygwin DOT com>
Sent: Tuesday, June 26, 2001 10:04 AM
Subject: pthreads works, sorta


> With Robert Collins' latest patches, the Cygwin pthreads
implementation,
> 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
under
> linux and proceeds to the point where the program thrashes because it
is
> 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
should
> come first and performance second.  However, one of our developers is
> insisting on writing his own pthreads implementation for the
application
> (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
code;
> 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
his
> valuable time.  However, as of 1.3, our application doesn't run on
Win32
> without kluging the threads implementation (by using a pthreads
implementation
> from ftp://sources.redhat.com/pub/pthreads-win32).  I am anxious to
see
> 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
concept
> of classes, objects and methods, some of the syntax and methodolgy
eludes
> 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
you
> don't know how deep it is, you don't jump in head first, and not feet
first,
> 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.

/Rob

> Greg
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple