Subj : Re: 'volatile' Rules
To   : comp.programming.threads
From : Marcin 'Qrczak' Kowalczyk
Date : Tue Jun 07 2005 09:43 pm

Joe Seigh <jseigh_01@xemaps.com> writes:

> This is not true.  It's nonsense even.  If someone wrote it into the
> documentation, they didn't know what they're talking about.

You are calling ISO/ANSI C nonsense?

From C99 draft:

       7.13.2.1  The longjmp function
[...]
       [#3]  All  accessible  objects  have  values  as of the time
       longjmp was called, except that the  values  of  objects  of
       automatic  storage  duration  that are local to the function
       containing the invocation of the corresponding setjmp  macro
       that  do  not  have  volatile-qualified  type  and have been
       changed between the setjmp invocation and longjmp  call  are
       indeterminate.
[...]

       7.14.1.1  The signal function
[...]
       [#5]  If  the  signal  occurs  other  than  as the result of
       calling  the  abort  or  raise  function,  the  behavior  is
       undefined  if  the  signal handler refers to any object with
       static storage duration other than by assigning a  value  to
       an  object  declared as volatile sig_atomic_t, or the signal
       handler calls any function in  the  standard  library  other
       than  the  abort  function  or  the signal function with the
       first argument equal to the signal number  corresponding  to
       the  signal  that  caused  the  invocation  of  the handler.
       Furthermore, if such a call to the signal  function  results
       in    a    SIG_ERR   return,   the   value   of   errno   is
       indeterminate.198)


In practice most programs using signals assume slightly more than
that, even though it's not formally guaranteed by ISO C or POSIX.
They assume that volatile variables which fit into machine word
are accessed atomically wrt. a signal handler. I haven't heard of
a platform where this is not true.

> Signal handling uses the same undocumented mechanisms for visibility
> that pthreads uses, except obviously they don't need memory barriers
> since it's all on the same thread.

This is the cruical point. They don't need memory barriers, so the
only things they need are:
- atomic access (true in practice for small types)
- that the compiler won't reorder accesses wrt. other side effects
  and wrt. one another (this is given by volatile)

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/

.