Do you really need volatile? There are two cases to consider. Either your code synchronizes updates to the shared value with the signal handler (e.g., by blocking and then unblocking the signal), in which case I believe the compiler cannot ignore updates to the value; or you don't, and you can't depend on the variable having any specific value in the signal handler. The only thing you want to prevent in the latter case is the handler observing a partial update to the variable, which I presume is where the other requirements originate. (In practice, there should be little or no concern with any primitive type on modern hardware). --Elad On Wed, Mar 20, 2024 at 4:32 PM Guilherme Janczak <guilherme.janczak@xxxxxxxxxx> wrote: > > Variables shared with signal handlers must be of type `volatile > sigatomic_t`, not `volatile` or `sigatomic_t` as the current text says, > according to a C11 draft: > > When ... interrupted by ... a signal, values of objects that are > neither lock-free atomic objects nor of type volatile sig_atomic_t > are unspecified. > > Ref: https://www.iso-9899.info/n1570.html#5.1.2.3p5 > Signed-off-by: Guilherme Janczak <guilherme.janczak@xxxxxxxxxx> > --- > memorder/memorder.tex | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/memorder/memorder.tex b/memorder/memorder.tex > index 5c50d42d..873c3424 100644 > --- a/memorder/memorder.tex > +++ b/memorder/memorder.tex > @@ -1317,8 +1317,8 @@ from the viewpoint of the interrupted thread, at least at the > assembly-language level. > However, the C and C++ languages do not define the results of handlers > and interrupted threads sharing plain variables. > -Instead, such shared variables must be \co{sig_atomic_t}, lock-free > -atomics, or \co{volatile}. > +Instead, such shared variables must be \co{volatile sig_atomic_t} or > +lock-free atomics. > > On the other hand, because the handler executes within the interrupted > thread's context, the memory ordering used to synchronize communication > -- > 2.42.0 > >
