In the case in your example, sleep() doesn't need to be implemented using SIGALRM. It isn't in glibc and OpenBSD that I know of: https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/posix/sleep.c;h=3df79097c4464510f0197138a00a0c9772a5e83e;hb=3ab9b88e2ac91062b6d493fe32bd101a55006c6a https://man.openbsd.org/sleep.3 I managed to make GCC and Clang optimize out a sig_atomic_t store: ``` #define _POSIX_C_SOURCE 200809L #include <sys/time.h> #include <stdio.h> #include <stdlib.h> #include <signal.h> #include <string.h> static void catch_sigalrm(int); #ifdef VOLATILE volatile sig_atomic_t msg; static const char *decl = "volatile sig_atomic_t msg"; #else sig_atomic_t msg; static const char *decl = "sig_atomic_t msg"; #endif volatile sig_atomic_t reply; volatile sig_atomic_t replied; int main(void) { const struct sigaction act = { .sa_handler = catch_sigalrm }; const struct itimerval timer = { .it_value.tv_usec = 1, .it_interval.tv_usec = 1, }; sigaction(SIGALRM, &act, NULL); setitimer(ITIMER_REAL, &timer, NULL); while (!replied) { msg = 1; } printf("%s == %d\n", decl, (int)reply); } static void catch_sigalrm(int unused) { int n = msg; if (!n) return; reply = n; replied = 1; } ``` This runs forever: ``` $ cc -O2 test2.c && ./a.out ``` This terminates: ``` $ clang -O2 -DVOLATILE test2.c && ./a.out volatile sig_atomic_t msg == 1 ``` Without volatile in its declaration, msg is never set, so the program spins forever because the signal handler never tells the loop to stop. There's probably a simpler way to do this. On Wed, Mar 20, 2024 at 07:20:03PM -0400, Elad Lahav wrote: > Actually, in the example I cited, there are multiple function calls > (printf, raise) between the two reads. How can the compiler optimize > out reading the value a second time? > > My view, which is subject to change at any moment and without notice, > is that you need volatile in the cases where you normally need > volatile, rather than inherently whenever you use sig_atomic_t. In the > following example I would not expect you to need it: > > static sig_atomic_t value; > > void > sig_handler(int signum) > { > value++; > } > > void > func(void) > { > value = 0; > sleep(1); > printf("There have been %d signals while I was napping\n", value); > } > > --Elad > > On Wed, Mar 20, 2024 at 7:05 PM Elad Lahav <e2lahav@xxxxxxxxx> wrote: > > > > No problem... > > Yes, in your example the issue is that the type is not atomic, and > > thus subject to partial updates that can be interrupted. > > Looking at the example given in > > https://en.cppreference.com/w/c/program/sig_atomic_t the volatile is > > needed to let the compiler know that the value can be updated in > > between two reads by the main function. That makes sense, especially > > if you have code that loops waiting for the value to change. > > > > --Elad > > > > On Wed, Mar 20, 2024 at 6:39 PM Guilherme Janczak > > <guilherme.janczak@xxxxxxxxxx> wrote: > > > > > > Actually, uh, I misread your reply, forget the previous reply I sent. > > > > > > You don't need the volatile with lock-free atomics, but the standard > > > says you do need it with sig_atomic_t. I don't know of a case that would > > > break a plain `sig_atomic_t` variable with no `volatile`, however. > > > > > > On Wed, Mar 20, 2024 at 04:44:33PM -0400, Elad Lahav wrote: > > > > 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 > > > > > > > > > > > > > >
