This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Nested calls to Mutexes
- To: martin at fatbob dot nu
- Subject: Re: [ECOS] Nested calls to Mutexes
- From: Jonathan Larmour <jlarmour at redhat dot com>
- Date: Wed, 04 Apr 2001 16:16:58 +0100
- Cc: Rosimildo daSilva <rosimildo at hotmail dot com>,ecos-discuss at sources dot redhat dot com
- Organization: Red Hat UK Ltd.
- References: <F309LwxTQTYkWSzsVA2000068c5@hotmail.com> <3ABA2C66.F14AF5A@redhat.com> <20010404170816.B9047@kungen.fatbob.nu>
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