This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: Nested calls to Mutexes
- To: Jonathan Larmour <jlarmour at redhat dot com>
- Subject: Re: [ECOS] Nested calls to Mutexes
- From: martin at fatbob dot nu
- Date: Wed, 4 Apr 2001 17:08:16 +0200
- Cc: Rosimildo daSilva <rosimildo at hotmail dot com>, ecos-discuss at sources dot redhat dot com
- References: <F309LwxTQTYkWSzsVA2000068c5@hotmail.com> <3ABA2C66.F14AF5A@redhat.com>
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).
I've run across this before, but it's easy to solve using some wrapper
function to create recursive mutexes.
Regards
/Martin
>
> And "undefined behavior" means anything from the recursive mutexes you want
> to contacting NORAD with the missile codes to start World War III.
>
> So don't do this, the world is in your hands. :-)
>
> 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
>