Use of "fast" mutexes in mupdate.c

[Dave McMurtrie]

Good morning,

I was reading through the mupdate.c code this morning looking for a
solution to a problem we're experiencing.  That led to me reading the
pthread_mutex_lock() manpage.  The mupdate.c code is using "fast"
mutexes.  pthread_mutex_lock() on Linux has this interesting feature:

----- begin quote -----
On ''error checking'' mutexes, pthread_mutex_unlock actually checks at
run-time that the mutex is locked on entrance, and that it was  locked
by the same thread that is now calling pthread_mutex_unlock.  If these
conditions are not met, an  error  code  is  returned  and  the  mutex
remains unchanged.  ''Fast'' and ''recursive'' mutexes perform no such
checks, thus allowing a locked mutex to be unlocked by a thread  other
than  its  owner. This is non-portable behavior and must not be relied upon.
----- end quote -----

Doesn't this mean that even if the code is properly written to lock
idle_worker_mutex before modifying the linked list of idle connections,
some other thread is free to unlock the mutex out from under us?

If that is the case, does anyone see a reason to not change this to use
"error-checking" mutexes and then add error checking to the
pthread_lock_mutex() and pthread_unlock_mutex() calls?  If performance
is the only potential impact, I'm willing to test it here and see if we
really need to be concerned.  As the code is currently written, it
doesn't appear to be thread-safe, at least on Linux.

Thanks,

Dave
-- 
Dave McMurtrie, SPE
Email Systems Team Leader
Carnegie Mellon University,
Computing Services