Different behaviour of mutex on Linux and QNX

I am using QNX6.3.2 on x86.

Attached the sample code that I ran on Linux(2.6.11-1.1369_FC4smp) and QNX. Below is the output
on both the systems.
Please clarify, why the behaviour is different?

Also, instead of
“pthread_mutexattr_settype(&mutexAttribute,PTHREAD_MUTEX_DEFAULT);”
if I use
“pthread_mutexattr_setrecursive(&mutexAttribute,PTHREAD_RECURSIVE_DISABLE);”
on QNX system, the behaviour is still the same with thread 1 being able to
recursively lock the mutex. Please clarify.


The output on Linux:
This is thread 1
Thread 1 - lock : 0
This is thread 2


The output on QNX:
This is thread 1
Thread 1 - lock : 0
Thread 1 - lock : 1
Thread 1 - lock : 2
Thread 1 - lock : 3
Thread 1 - lock : 4
Thread 1 - lock : 5
Thread 1 - lock : 6
Thread 1 - lock : 7
Thread 1 - lock : 8
Thread 1 - lock : 9
This is thread 2


vamsy,

According to QNX documentation, pthread_mutex_lock() returns an error EDEADLK if you try to lock a mutex you already own and the mutex is not recursive. It is a good idea to check always the return value of system calls.
The behaviour of Linux seems bad in my eyes as this results in a mutex blocked forever (aka dead lock). Maybe Linux has also different variants of mutexes with different behaviour?

-Peter

According to IEEE Std 1003.1 (POSIX):

“If the mutex type is PTHREAD_MUTEX_DEFAULT, attempting to recursively lock the mutex results in undefined behavior.”

-Peter

Hi Peter,
Thanks for your response. I guess I was just expecting the same behavior as on Linux. So, wasn’t checking for return value. I think for my kind of requirement where I need to block the thread when tried to lock again, I must use PTHREAD_MUTEX_NORMAL as the type on QNX.

Thanks,
Vamsy

I hope this thread isn’t controlling something vitally important ;-)

-Peter