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
Content-Type: text/plain;
	charset="iso-8859-1"
Subject: RE: muto object.
X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0
Date: Mon, 17 Sep 2001 12:24:53 +1000
Message-ID: <EA18B9FA0FE4194AA2B4CDB91F73C0EF08F17C@itdomain002.itdomain.net.au>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: muto object.
Thread-Index: AcE/H6k9VWCVsUVLTCmRyUtTMGVaIgAAAYRA
From: "Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To: <cygwin-developers AT cygwin DOT com>
Cc: <cygwin-patches AT cygwin DOT com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id WAA28975

I'll try finishing the email this time.

What I meant to say was, if this looks ok, it makes muto's a potential
replacement for critical sections on 95 for pthreads, which would be
very good speed wise.

Anyway, I'll draw up a change log and the rest if you want this
included.

Rob

> -----Original Message-----
> From: Robert Collins 
> Sent: Monday, September 17, 2001 12:23 PM
> To: cygwin-developers AT cygwin DOT com
> Cc: cygwin-patches AT cygwin DOT com
> Subject: muto object.
> 
> 
> Chris, 
>   This update to muto handles threads exiting spontaneously without
> releasing the muto properly. I think it fixes the FIXME you have in
> ::release, but as I can't see how release can check for other thread
> activity, it may not have fixed that.
> 
> The logic it uses is:
> if we fail to wait for the event,
> protect ourselves with recover
> check for the thread having died (should be fast - noop basically) and
> if it has aquire the muto anyway.
> 
> There was also a typo in the destructor that could be causing memory
> leaks within process.
> 
> Rob
>