From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jonathan Larmour To: martin@fatbob.nu Cc: Rosimildo daSilva , ecos-discuss@sources.redhat.com Subject: Re: [ECOS] Nested calls to Mutexes Date: Wed, 04 Apr 2001 08:17:00 -0000 Message-id: <3ACB3AE9.10215724@redhat.com> References: <3ABA2C66.F14AF5A@redhat.com> <20010404170816.B9047@kungen.fatbob.nu> X-SW-Source: 2001-04/msg00031.html martin@fatbob.nu wrote: > > On Thu, Mar 22, 2001 at 04:46:30PM +0000, Jonathan Larmour wrote: > > > [ Sent this yesterday but it bounced! ] > > > > Rosimildo daSilva wrote: > > > > > > Many implementations out there support the concept of > > > nested/balanced mutex calls. That is the programmer's > > > expectation. Sorry, to put this way, but I consider > > > this a *bug*. > > > > POSIX doesn't. Quite the opposite in fact, and that's hardly an obscure > > standard.... > > "An attempt by the current owner of a mutex to relock the mutex results in > > undefined behavior". > > Well, this isn't entirely true. The default behaviour is as you describe, but > this can be changed using pthread_mutexattr_setkind_np(attr, kind) > where kind can take the value PTHREAD_MUTEX_RECURSIVE_NP to create recursive > mutexes (reading from the man page for pthread_mutexattr_setkind_np(3) > contained in glibc 2.2). pthread_mutexattr_setkind_np() is not a POSIX function. It's purely a glibc extension. > I've run across this before, but it's easy to solve using some wrapper > function to create recursive mutexes. Quite. Jifl -- Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062 Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine