Bug 26247

Summary: Does pthread_mutex_trylock really work on the latest FreeBSD release if the mutex is already reserved?
Product: Base System Reporter: Heikki.Tuuri <Heikki.Tuuri>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Unspecified   
Hardware: Any   
OS: Any   

Description Heikki.Tuuri 2001-03-31 18:40:01 UTC
Hi FreeBSD people!

Dan Nelson reported a hang in the MySQL/Innobase engine. It seems
that the FreeBSD code gets into an infinite loop when
pthread_mutex_trylock is tried on a mutex already locked.

My code works on Linux-Intel and Solaris-Sparc. Could the problem have
something to do with thread signal masks or something?

You can view Innobase source code at www.bitkeeper.com,
Hosted repositories, mysql, subdirectory innobase.

Regards,

Heikki Tuuri
Innobase Oy

...............
Thank you Dan!

I do not have access to a FreeBSD computer during this weekend but
your stack prints already tell the origin of the problem.

I have implemented my own mutexes in the purpose that I can use
an assembler instruction for the atomic test-and-set operation
needed in a mutex. But for now I have done the test-and-set
with pthread_mutex_trylock: it provides an atomic operation
on an OS mutex which I can use in place of test-and-set.

It seems that if a thread does not acquire a mutex with the
first try, then something goes wrong and the thread is left in a loop.
The stack prints show that FreeBSD uses a spin wait also in the
case a trylock fails. This may be associated with the problem.
More logical would be that FreeBSD would return with a failure
code if trylock fails.

A fix would be to replace pthread_mutex_trylock with
the XCHG instruction to implement test-and-set. But that would not
work on non-Intel FreeBSD platforms.

I will dig into the FreeBSD documentation and try to find a
solution from there.

Best regards,

Heikki

At 03:52 PM 3/30/01 -0600, you wrote:

How-To-Repeat: Seems to hang always.
Comment 1 Daniel Eischen freebsd_committer freebsd_triage 2001-04-10 05:41:37 UTC
State Changed
From-To: open->closed

This was really an application bug, not a bug in the threads 
library.  The application had a low priority thread that held 
a mutex needed by a higher priority thread.  The higher priority 
thread kept spinning (pthread_mutex_trylock) waiting for the 
lower priority thread to release the mutex.  The lower priority 
thread got starved and never got a chance to run.