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
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?
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.