From: Laurence Tratt <laurie@tratt.net>
Subject: Re: sys/sysctl: make hw.setperf MP safe
To: tech@openbsd.org
Date: Fri, 23 May 2025 13:29:13 +0100

On Thu, May 22, 2025 at 05:41:07PM -0400, Ted Unangst wrote:

Hello Ted,

> We may as well just add a prebuild step that runs the entire kernel
> through a sed script that changes everything to atomic, then we can
> continue writing normal code.

I don't do much kernel work, but I have done quite a lot of parallel code
that conforms to the C11 memory model.

In general, I'd be less worried by tearing (though it can happen), but more
worried about the compiler statically optimising away things when it
"knows" it can only be accessed by the current thread. For example -- and
this one boggled my mind when I first saw it -- I have seen clang remove a
`memset` call entirely when it could prove that the heap effects were local
to the current thread. [The programmer in this case wanted the effects to
be seen by another thread, but hadn't added the necessary fence/barrier
after `memset`, so the compiler was correct w.r.t. C's semantics! This is,
to my mind, a more complex variant of "this integer is not loaded with
atomic operations".]

FWIW, I have, over time, become decidedly unkeen on the idea of an "atomic
load" without an associated "ordering". When I see
`atomic_load_explicit(&x, memory_order_relaxed)` I (and the compiler and,
depending on the architecture, the CPU) interpret how that value is used
very differently than `atomic_load(&x)`. I still haven't ever used a
sequentially consistent load, except when I thought I'd made a mistake
elsewhere and hoped it might mask it...


Laurie