diff options
| author | riastradh <riastradh@NetBSD.org> | 2022-02-12 17:10:02 +0000 |
|---|---|---|
| committer | riastradh <riastradh@NetBSD.org> | 2022-02-12 17:10:02 +0000 |
| commit | eca597be02388df1272b3a1ff3ebbddbc284b120 (patch) | |
| tree | 8f4eabb570e82a2bb33875c84ea952a45412ab02 /usr.bin/script | |
| parent | e92dc8adfa2d8e3dc01f5b244727e8d769941041 (diff) | |
mips: Brush up __cpu_simple_lock.
- Eradicate last vestiges of mb_* barriers.
- In __cpu_simple_lock_init, omit needless barrier. It is the
caller's responsibility to ensure __cpu_simple_lock_init happens
before other operations on it anyway, so there was never any need
for a barrier here.
- In __cpu_simple_lock_try, leave comments about memory ordering
guarantees of the kernel's _atomic_cas_uint, which are inexplicably
different from the non-underscored atomic_cas_uint.
- In __cpu_simple_unlock, use membar_exit instead of mb_memory, and do
it unconditionally.
This ensures that in __cpu_simple_lock/.../__cpu_simple_unlock, all
memory operations in the ellipsis happen before the store that
releases the lock.
- On Octeon, the barrier was omitted altogether, which is a bug --
it needs to be there or else there is no happens-before relation
and whoever takes the lock next might see stale values stored or
even stomp over the unlocking CPU's delayed loads.
- On non-Octeon, the mb_memory was sync. Using membar_exit
preserves this.
XXX On Octeon, membar_exit only issues syncw -- this seems wrong,
only store-before-store and not load/store-before-store, unless the
CNMIPS architecture guarantees it is sufficient here like
SPARCv8/v9 PSO (`Partial Store Order').
- Leave an essay with citations about why we have an apparently
pointless syncw _after_ releasing a lock, to work around a design
bug^W^Wquirk in cnmips which sometimes buffers stores for hundreds
of thousands of cycles for fun unless you issue syncw.
Diffstat (limited to 'usr.bin/script')
0 files changed, 0 insertions, 0 deletions
