Questions about mutex implementation in kern/kern_mutex.c

Andrey Simonenko simon at comsys.ntu-kpi.kiev.ua
Wed Sep 15 14:02:15 UTC 2010


Hello,

I have questions about mutex implementation in kern/kern_mutex.c
and sys/mutex.h files (current versions of these files):

1. Is the following statement correct for a volatile pointer or integer
   variable: if a volatile variable is updated by the compare-and-set
   instruction (e.g. atomic_cmpset_ptr(&val, ...)), then the current
   value of such variable can be read without any special instruction
   (e.g. v = val)?

   I checked Assembler code for a function with "v = val" and "val = v"
   like statements generated for volatile variable and simple variable
   and found differences: on ia64 "v = val" was implemented by ld.acq and
   "val = v" was implemented by st.rel; on mips and sparc64 Assembler code
   can have different order of lines for volatile and simple variable
   (depends on the code of a function).

2. Let there is a default (sleep) mutex and adaptive mutexes is enabled.
   A thread tries to obtain lock quickly and fails, _mtx_lock_sleep()
   is called, it gets the address of the current mutex's owner thread
   and checks whether that owner thread is running (on another CPU).
   How does _mtx_lock_sleep() know that that thread still exists
   (lines 311-337 in kern_mutex.c)?

   When adaptive mutexes was implemented there was explicit locking
   around adaptive mutexes code.  When turnstile in mutex code was
   implemented that's locking logic was changed.

3. Why there is no any memory barrier in mtx_init()?  If another thread
   (on another CPU) finds that mutex is initialized using mtx_initialized()
   then it can mtx_lock() it and mtx_lock() it second time, as a result
   mtx_recurse field will be increased, but its value still can be
   uninitialized on architecture with relaxed memory ordering model.

Thanks.


More information about the freebsd-hackers mailing list