Pthread_mutex_lock locks but owner not set

Question

I have been working on this for several days -

As a background, I am working on a single-threaded C program and making it multithreaded. I recently discovered a new dead end case, but when I look at the mutex in gdb, I see that

__ lock = 2 more __owner = 0

This is not a recursive mutex. Has anyone seen this? The program I'm working on is a daemon, and this case only happens after executing with high throughput for more than 20 minutes (approximately), and then easing the load. If you have any ideas, I would be grateful.

Edit - I forgot to mention that all my other threads are currently inactive.

Greetings

Answer 1

As far as I can tell, this is due to the limitation of the pthread library. Whenever I found pieces of code that use excessive locking and unlocking and strongly emphasize this piece of code, I had such a failure. I decided to rewrite these sections to minimize their blocking, which simplifies the code (less error checking when re-acquiring potentially freed objects) and eliminates some overhead.

Answer 2

This is to be expected. The regular (non-recursive, non-errorchecking) mutex does not need to be stored by its owner, and you can save it for some time by skipping the search step for the caller's thread identifier. (This is not unlike x86, but it can be a huge difference on platforms such as MIPS with broken ABIs where there is no thread register, and getting the thread ID causes an error in kernelspace.)

The deadlock you see is almost certainly due to either a thread trying to block an existing mutex, or an actual logical error in which two or more threads are expecting deadlocks that the other holds.

Answer 3

I just fixed the problem I was facing - stack damage caused the mutex.__data.__lock value to be set to some ridiculous number (4 billionth) immediately before trying to call pthread_mutex_lock . See if you can set a breakpoint or print debugging information using the __lock value just before the blocking operation is executed, and I am ready to invalidate the bet before the deadlock occurs.