delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/2001/09/12/21:36:37

Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-developers-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin-developers AT sources DOT redhat DOT com
content-class: urn:content-classes:message
MIME-Version: 1.0
Subject: RE: Quick testfeedback...
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Thu, 13 Sep 2001 11:23:54 +1000
Message-ID: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F16A@itdomain002.itdomain.net.au>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: Quick testfeedback...
Thread-Index: AcE76rc54CK7Cnt2RJGxtBzlqTwcngAB3oQA
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id VAA23652

What would be most useful (more useful than tryentercritical section in
some ways) would be
ReleaseCriticalSectionAndWait

AFAIK SignalObjectAndWait won't signal a CriticalSection, so we have a
race in pthread_cond_timedwait. (pthread_cond_wait is a wrapper around
timedwait).

That would mean that condition variables don't need to use real mutex's
to prevent races, and allow the current speed to be kept. (On my todo is
to drop cond variables back to using win32mutex's because of this).

TryEnterCriticalSection would be good of course, but without
ReleaseCriticalSectionAndWait or SignalObjectAndWait it will suffer the
same race forever, unless I can find some way to protect the
release+wait without utilising a syncronisation object :]. Mind you, on
a single CPU it's much harder to trigger such races than multiCPU.

Rob

> -----Original Message-----
> From: Christopher Faylor [mailto:cgf AT redhat DOT com]
> Sent: Thursday, September 13, 2001 10:39 AM
> To: cygwin-developers AT cygwin DOT com
> Subject: Re: Quick testfeedback...
> 
> 
> On Thu, Sep 13, 2001 at 08:46:41AM +1000, Robert Collins wrote:
> >On Thu, 2001-09-13 at 03:23, Christopher Faylor wrote:
> >> I *am* concerned about YA performance hit on Windows 9x, 
> though.  I'd like
> >> to avoid that if possible.
> >
> >No hit, its been like it is now since day 1. (Well actually there was
> >the process wide mutex serialisation when I first started 
> hacking at it,
> >but thats long gone).
> >
> >I just had the opportunity to make NT *faster*.
> 
> I noticed.  It's noticeably faster.
> 
> In fact, for some reason, cygwin *feels* faster now.  It 
> seems to start
> up zsh much more quickly.
> 
> I"m wondering if this is, in part, due to the use of critical sections
> in reading /etc/passwd.  I can't believe that it would have 
> that noticeable
> an effect but I don't know what else to attribute it to.  It 
> seems faster
> than 1.3.2.
> 
> I guess I just worry about the potential for cygwin mailing 
> list whines
> about slowness on 9x.  Maybe I'm getting overly sensitve to that.  :-)
> 
> And, getting our own implementation of TryEnterCriticalSection is
> something I'd always wanted to try.
> 
> cgf
> 

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019