Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Subject: RE: pthread_mutex_trylock does not lock
From: Robert Collins <rbcollins AT cygwin DOT com>
To: Christophe Galerne <christophegalerne AT earthlink DOT net>
Cc: cygwin <cygwin AT cygwin DOT com>
In-Reply-To: <3DEE74C3.1070208@earthlink.net>
References: <3DEE74C3 DOT 1070208 AT earthlink DOT net>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature";
	boundary="=-3QWSPMHlhaZCVeHgcTMj"
Date: 05 Dec 2002 18:51:37 +1100
Message-Id: <1039074697.8812.24.camel@lifelesswks>
Mime-Version: 1.0

--=-3QWSPMHlhaZCVeHgcTMj
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2002-12-05 at 08:33, Christophe Galerne wrote:


> This
> www.opengroup.org/onlinepubs/7908799/xsh/pthread_mutexattr_settype.html
> seems to explain that a PT_MUTEX_NORMAL mutex should behave the way Chris
> expect.

NB: PT_MUTEX_NORMAL is not a posix mutex type - it's
PTHREAD_MUTEX_NORMAL.... And yes, 'NORMAL' mutexs deadlock on relocking
attempts.

Thomas Pfaff is currently updating the cygwin mutex support - it would
be great to get some user feedback on his patches, and they support
PTHREAD_MUTEX_NORMAL mutex's.

>  > We don't support NONRECURSIVE mutex's. I don't know what you mean by
>  > NORECURSIVE threads.
>=20
> Then maybe one should add a comment above
> pthread.h(55): #define PTHREAD_MUTEX_NORMAL 2
> that this option is not supported.

Or you could check the return value from pthread_mutexattr_settype and
see that it returns EINVAL.

> Also above
> pthread.h(57): #define PTHREAD_MUTEX_INITIALIZER (void *)20
> a comment that says that a default MUTEX will be recursive
> might avoid some surprise. =3D:-D

Look at pthread.h:53 and pthread.h:58. DEFAULT is mapped to RECURSIVE as
per the 1003.1 options 'an implementation may map this mutex to one of
the other mutex types'. Thus my initial comment: ASSUMING that
PTHREAD_MUTEX_DEFAULT =3D=3D PTHREAD_MUTEX_NORMAL is broken code.=20

Rob


--=20
---
GPG key available at: http://users.bigpond.net.au/robertc/keys.txt.
---

--=-3QWSPMHlhaZCVeHgcTMj
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQA97wWII5+kQ8LJcoIRAkVwAJ9a1QweLfVgw/lS+YzfU1b0oltCjACguDxo
qBmHHt65PWo5hQF7CeGVdrY=
=wHS+
-----END PGP SIGNATURE-----

--=-3QWSPMHlhaZCVeHgcTMj--