Use of "fast" mutexes in mupdate.c

[Wesley Craig]

On 30 Mar 2009, at 08:52, Dave McMurtrie wrote:
> I was reading through the mupdate.c code this morning looking for a
> solution to a problem we're experiencing.

What problem is that?

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

In properly written code, all of the threads are working together.   
Thus, while any thread is free to (incorrectly) unlock a critical  
mutex that they have no business messing with, in properly written  
code, they don't.  That would be a bug.

PTHREAD_MUTEX_NORMAL, _ERRORCHECK, and _RECURSIVE are specified in  
POSIX, BTW.

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

Which platforms are you thinking of testing it on?  I could well  
imagine Linux doing very well with this error checking enabled, while  
other platforms might suffer quite a bit.  I think the thing to keep  
in mind is that the error checking code is really there for  
debugging.  Much like you might fill code you are testing with  
printf's, once you're done debugging, you remove that code.

So, in summary, if using PTHREAD_MUTEX_ERRORCHECK is going to help  
you track down whatever problem you're having, you should definitely  
use it.

:wes