Here's the actual code I had in mind: #include <stdio.h> #include <stdlib.h> #include <stdint.h> #include <signal.h> #include <time.h> #include <unistd.h> static sig_atomic_t value; static void sig_handler(int const signum) { value++; } int main(int argc, char **argv) { // Install a signal handler for SIGUSR1. struct sigaction act = { .sa_handler = sig_handler }; if (sigaction(SIGUSR1, &act, NULL) == -1) { perror("sigaction"); return EXIT_FAILURE; } // Create a timer to dispatch signals. struct sigevent event; SIGEV_SIGNAL_INIT(&event, SIGUSR1); timer_t timerid; if (timer_create(CLOCK_MONOTONIC, &event, &timerid) == -1) { perror("timer_create"); return EXIT_FAILURE; } // Start the timer to fire every 10ms. struct itimerspec ts = { .it_value.tv_nsec = 10000000UL, .it_interval.tv_nsec = 10000000UL }; if (timer_settime(timerid, 0, &ts, NULL) == -1) { perror("timer_settime"); return EXIT_FAILURE; } // Wait for one second. // Can't use sleep(), as that call will be interrupted. uint64_t const start = clock_gettime_mon_ns(); for (;;) { uint64_t const now = clock_gettime_mon_ns(); if ((now - start) > 1000000000UL) { break; } } printf("There were %d signals while I was napping\n", value); return EXIT_SUCCESS; } --Elad On Wed, Mar 20, 2024 at 9:03 PM Elad Lahav <e2lahav@xxxxxxxxx> wrote: > > Sorry, that's not at all what I meant. I used sleep() just to simulate > the main function doing something while signals arrive asynchronously. > What you gave in your example is exactly the situation that does > require volatile, per my previous email, as the main function > constantly polls the shared value without any function calls in reads. > > --Elad > > On Wed, Mar 20, 2024 at 8:34 PM Guilherme Janczak > <guilherme.janczak@xxxxxxxxxx> wrote: > > > > 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 > > > > > > > > > > > > > > > > > > > >