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
> > > >
> > > >
> > >
