re: pthread-mutex debugging (PR#44387)

[matthew green <mrg%eterna.com.au@localhost>]

> today I spent some time on debugging PR #44387 (some pthread mutex tests
> run forever). As Jeff Rizzo wrote, the problem disappears when compiling
> a kernel with DIAGNOSTIC option.
> 
> I could now isolate the problem on sys/kern/kern_mutex.c. It was
> sufficient to compile kern_mutex.c with -DFULL to make the problem
> disappear. The rest of the kernel was compiled without DIAGNOSTIC.
> 
> FULL enables the use of __cpu_simple_lock_try() and __cpu_simple_unlock()
> when locking/unlocking a mutex, which sets/unsets a variable in an
> atomic operation.
> 
> Unfortunately I still don't see what is wrong here. I fear the problem
> is somewhere else and using the "full" locking code hides it somehow.

can you confirm what code is being compiled and called from where?

i'm assuming that the non debug kernel with -DFULL in kern_mutex.c
kernel (that fails) has lock_stubs.s:mutex_enter() calling into
mutex_vector_enter().  (same with exit.)

you could try disabling this parts to see what happens:

#define __HAVE_MUTEX_STUBS              1


is this a spin or adaptive mutex?


.mrg.