| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
ok visa@, kettenis@
|
|
|
|
|
|
| |
prepare the terrain for MI locks.
ok kettenis@
|
|
|
|
|
|
|
|
|
|
|
| |
each arch used to have to provide an rw_cas operation, but now we
have the rwlock code build its own version. on smp machines it uses
atomic_cas_ulong. on uniproc machines it avoids interlocked
instructions by using straight loads and stores. this is safe because
rwlocks are only used from process context and processes are currently
not preemptible in our kernel. so alpha/ppc/etc might get a benefit.
ok miod@ kettenis@ deraadt@
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
this basically replaces sparc64_cas and sparc64_casx with atomic_cas_uint
and atomic_cas_ulong respectively. it then builds atomic_add and
atomic_sub out of those. this avoids the gcc atomic builtins that
the MI atomic_foo api uses by default, so we dont get the extra
membars that the builtins do but the atomic_foo api doesnt promise.
it also fixes up the code that used to use sparc64_{cas,casx} to
use the atomic_cas api instead.
use of the sparc64 membar() macros are left untouched for now.
ok kettenis@
|
|
|
|
| |
part of the future we have planned. middling ok from a few
|
|
|
|
|
|
| |
spinning on a contended lock.
ok kettenis@
|
|
|
|
| |
Discussed and okay drahn@. Okay deraadt@.
|
|
|
|
| |
guenther@ for sparc, pointed out to me by miod@.
|
|
|
|
| |
on drugs; ok kettenis@
|
| |
|
|
|
|
| |
ok kettenis@
|
|
unconditionnaly.
|