pthread_mutex_trylock() hangs

[kaliber]

If a mutex is already locked, pthread_mutex_trylock() should return EBUSY instead of hanging.

Specification: ​http://www.opengroup.org/onlinepubs/000095399/functions/pthread_mutex_lock.html

Test case: ​http://posixtest.cvs.sourceforge.net/viewvc/posixtest/posixtestsuite/conformance/interfaces/pthread_mutex_trylock/4-1.c?revision=1.2&view=markup

[bonefish]

Confirmed. The pthread_mutex_trylock() implementation is incorrect. It should not even touch the semaphore, but instead use atomic_test_and_set() on the count. Moreover the kernel's thread_block_with_timeout_locked() needs to check for an overflow in case B_TIMEOUT_REAL_TIME_BASE is set.

[stippi]

I've looked into this problem a bit, but I am not quite sure why the pthread_mutex_trylock() implementation is the problem (also from talking to Axel). I understand that by doing what it does, it potentially converts a benaphore style mutex into a semaphore based one. Is the hanging problem then in the kernel implementation with the 0 absolute timeout? If pthread_mutex_trylock() only touches the count, how would it work when the mutex has alreasy been converted to be semaphore based?

[stippi]

The WebCore trylock asserts work now (don't hang a WebPositive debug build on start-up anymore). Kaliber, can you please check if this bug is fixed for your test-cases as well?

[kaliber]

Replying to stippi:

The WebCore trylock asserts work now (don't hang a WebPositive debug build on start-up anymore). Kaliber, can you please check if this bug is fixed for your test-cases as well?

Yes, it's fixed.

[stippi]

Nice. Fixed in hrev36323 then.