CVSROOT: /cvs
Module name: src
Changes by: d...@cvs.openbsd.org 2015/04/17 06:38:54
Modified files:
sys/arch/alpha/alpha: mutex.c
sys/arch/alpha/include: mutex.h
Log message:
while trying to reproduce lockups on mp alpha i hit an
MUTEX_ASSERT_UNLOCKED, but it turns out alpha mutexes arent very
friendly to diagnostics on smp systems.
alpha mutexes contained an mtx_lock member. when 0 the mutex was
unlocked, and when 1 it was locked. the MUTEX_ASSERT_UNLOCKED checked
if mtx_lock was 1 to see if the current cpu owned the mutex, but
in an mp system another cpu may have set mtx_lock to 1, which causes
the assert to fire.
this changes alpha mutexes so they record which cpu owns the lock
rather than just if the lock is held or not. the diagnostics compare
the owner to the current cpus curcpu() address so they can actually
tell if the current cpu holds the lock instead of whether any cpu
holds the lock.
instead of using custom asm to implement a cas this uses atomic_cas_ptr,
which on alpha uses gcc cas code. miod says he has far more confidence
in the gcc cas than the code that was there before.
while im here i also shuffled the code. on MULTIPROCESSOR systems
instead of duplicating code between mtx_enter and mtx_enter_try,
mtx_enter simply loops on mtx_enter_try until it succeeds.
this also provides an alternative implementation of mutexes on
!MULTIPROCESSOR systems that avoids interlocking opcodes. mutexes
wont contend on UP boxes, theyre basically wrappers around spls.
we can just do the splraise, stash the owner as a guard value for
DIAGNOSTIC and return. similarly, mtx_enter_try on UP will never
fail, so we can just call mtx_enter and return 1.
ok miod@
