Does POSIX define what happens when a pthread currently holding a mutex
locks the same mutex?

i.e.

void f()
{
pthread_mutex_lock(&some_mutex);
pthread_mutex_lock(&some_mutex);
}

The Linux (MDK9.1) implementation of pthreads has a non-portable mutex
attribute letting you specify what behavior you want in said situation.

I'd like to try to write portable code, though.

[ Post a follow-up to this message ]

red floyd <no.spam@here.dude> writes:

> Does POSIX define what happens when a pthread currently holding a
> mutex locks the same mutex?

Yes, see

[url]http://www.opengroup.org/onlinepubs/009695399/functions/pthread_mutex_lock.html[/u
rl]

Joe
--
We can't all be heroes because someone has to sit on the curb and
clap as they go by.
- Will Rogers

[ Post a follow-up to this message ]

red floyd <no.spam@here.dude> writes:


>Does POSIX define what happens when a pthread currently holding a mutex
>locks the same mutex?

>i.e.

>void f()
>{
>    pthread_mutex_lock(&some_mutex);
>    pthread_mutex_lock(&some_mutex);
>}

>The Linux (MDK9.1) implementation of pthreads has a non-portable mutex
>attribute letting you specify what behavior you want in said situation.

>I'd like to try to write portable code, though.

Portable:

pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);

Casper
--
Expressed in this posting are my opinions.  They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.

[ Post a follow-up to this message ]

Casper H.S. Dik wrote:
> red floyd <no.spam@here.dude> writes:
>
>
> 
>
> 
>
> 
>
> 
>
> 
>
>
> Portable:
>
> pthread_mutexattr_settype(&attr, PTHREAD_MUTEX_RECURSIVE);
>
> Casper

OK, thanks Joe and Casper.  I guess my systems implementation is older,
and thus the recursive mutex hadn't yet been standardized or something.
So I'll simply #define something like this

#ifdef USE_NON_PORTABLE_RECURSIVE_MUTEX_
#define  RECURSIVE_MUTEX_ATTR	PTHREAD_MUTEX_RECUR
SIVE_NP  /* MDK9.1 */
#else
#define  RECURSIVE_MUTEX_ATTR	PTHREAD_MUTEX_RECUR
SIVE     /* other */
#endif

and use RECURSIVE_MUTEX_ATTR, so that I don't have to worry about it in
the future.

[ Post a follow-up to this message ]

red floyd wrote: ...

Don't use recursive mutexes. It's akin to sex with used condoms. ;-)

regards,
alexander.

[ Post a follow-up to this message ]

Hello,

> Don't use recursive mutexes. It's akin to sex with used condoms. ;-)

what's going on, Alexander? Are you now using now sentences that everybody c
an
understand?

I am not used to that ;-)

Cheers,
Loic.
--
Article posté via l'accès Usenet http://www.mes-news.com
Accès par Nnrp ou Web

[ Post a follow-up to this message ]

> Don't use recursive mutexes. It's akin to sex with used condoms. ;-)

YIKES!

[ Post a follow-up to this message ]

Alexander Terekhov wrote:
> red floyd wrote: ...
>
> Don't use recursive mutexes. It's akin to sex with used condoms. ;-)
>
> regards,
> alexander.

May I ask why?

[ Post a follow-up to this message ]

red floyd wrote:

> May I ask why?

There are two possibilities:

1) You don't know the mutex is being used recursively. In this case, the
recursive mutex will hide a serious problem.

2) You know the mutex is being recursively. In this case, just don't
lock it since you know it's already locked anyway.

The problem is that recursive mutexes hide something from you and that
something is extremely important. Consider code like this:

A) Lock mutex
B) Unlock mutex
C) Do something, assuming the mutex is unlocked

What happens if the mutex is recursive?

The only value of a recursive mutex is that it allows you to write a
function that works properly whether or not a mutex is locked. But the
caller must know that the mutex is locked anyway, so why not just have two
versions of the function? (With the one you call without a lock possibly
just being a wrapper that grabs the lock and calls the other function.)

It's just too hard and dangerous to write sensible code that works with
a mutex that might or might not start out with that mutex locked and with no
way to tell which. And the only value of recursive mutexes is that they let
you do this.

DS

[ Post a follow-up to this message ]

>     It's just too hard and dangerous to write sensible code that works
with
> a mutex that might or might not start out with that mutex locked and with
no
> way to tell which. And the only value of recursive mutexes is that they
let
> you do this.

There good for hashed locks.

[ Post a follow-up to this message ]