Subj : Re: 'volatile' Rules
To   : comp.programming.threads
From : Joe Seigh
Date : Tue Jun 07 2005 05:54 pm

Marcin 'Qrczak' Kowalczyk wrote:
> 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?

Yes.

> 
> 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.
> [...]

There are a finite amount of registers.  You can't put an indefinite
amount of variables in registers at the same time no matter what the
standard says.  And all setjmp/longjmp do is basically save/restore
registers.  Furthermore, C has no mechanism to force stuff to be
register only.  Basically, everything starts out as register class
and the compiler looks for reasons to move to memory class, e.g.
external references.  It's not clear how much C actually knows about
signal handling so you might have to be careful how you set up stuff
that's shared between a signal handler and the main program.  You
have to ensure the compiler recognizes that the data may be shared.

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

They assume too much.  Volatile doesn't mean anything here.
> 
> 
>>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)

It's not guaranteed by volatile.


-- 
Joe Seigh

When you get lemons, you make lemonade.
When you get hardware, you make software.

.