Mailing-List: contact cygwin-developers-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 Content-Type: text/plain; charset="iso-8859-1" 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: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Quick testfeedback... Thread-Index: AcE76rc54CK7Cnt2RJGxtBzlqTwcngAB3oQA From: "Robert Collins" To: Content-Transfer-Encoding: 8bit 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 >