Hi,
Somehow, all messages from Guilherme ended up in my spam folder
and I couldn't follow this thread properly earlier. I think I now
see the context.
On Thu, 28 Mar 2024 12:30:26 -0400, Elad Lahav wrote:
> Looks like this patch wasn't merged. Regardless of my
> questions/observations, Guilherme is absolutely right that volatile is
> required for sig_atomic_t by the standard. It may also need to be
> mentioned that, despite its name, the only operations that can be
> safely done on sig_atomic_t are store and load - it does not provide
> read/modify/write atomicity, unlike the lock-free atomic types. The
> standard says so, but it's easy to miss:
>
> "the signal handler refers to an object with static or thread storage
> duration that is not a
> lock-free atomic object other than by *assigning* a value to an object
> declared as
> volatile sig_atomic_t"
Hmm.
perfbook's (or LKMM's) style of *not* putting volatile at variable
declarations, but marking accesses to shared variable with
READ_ONCE()/WRITE_ONCE() when needed does not require the shared
object to be declared as "volatile sig_atomic_t".
As far as I can see, that is Paul's take throughout perfbook.
There are a couple of mentions to sig_atomic_t elsewhere.
Footnote 9 in Chapter 4:
That said, the various standards committees would prefer that
you use atomics or variables of type sig_atomic_t, instead of
READ_ONCE() and WRITE_ONCE().
Answer to Quick Quiz 5.54:
The theft variable must be of type sig_atomic_t to guarantee
that it can be safely shared between the signal handler and
the code interrupted by the signal.
If Guilherme's change is to be accepted, above sentences may need
some rewording as well for consistency, I guess.
My preference is to keep Listings 5.17 and 5.18 intact.
Sidenote:
You might be interested in Linus' recent remark on volatile
casting of LKMM vs C/C++ standards on volatile declaration at:
https://lore.kernel.org/lkml/CAHk-=wjP1i014DGPKTsAC6TpByC3xeNHDjVA4E4gsnzUgJBYBQ@xxxxxxxxxxxxxx/
(Warning: lengthy thread)
I'm not saying I agree 100% with him, but I'm accustomed to LKMM's
way so much that I don't like to see variables declared volatile... :-/
Thanks, Akira
