Subj : Re: 'volatile' Rules
To   : comp.programming.threads
From : Marcin 'Qrczak' Kowalczyk
Date : Wed Jun 08 2005 12:33 am

Joe Seigh <jseigh_01@xemaps.com> writes:

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

http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Incompatibilities.html

The intent is to allow the compiler to put variables in different
registers in different parts of a function, or different variables in
the same register, even if the compiler doesn't analyse control flow
caused by setjmp. ISO/ANSI C makes this allowance the default, even
in functions which call setjmp, and this can be disabled by volatile.

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

It ensures that the main program doesn't cache the variable in a
register, so that its change by a signal handler will be seen
immediately when the main program accesses it, and its change by the
main program will be seen immediately if a signal arrives shortly
after.

volatile variables are the only reliable means of communication of
data between a signal handler and the main program.

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

It is. This is the very definition of volatile in C/C++.

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

.