Paul Eggert <[EMAIL PROTECTED]> writes:
> Ben Pfaff <[EMAIL PROTECTED]> writes:
>
>> This is a particularly pessimistic interpretation of the
>> standard,
>
> You think _I'm_ pessimistic! You should hear Nick MacLaren and Dave
> Butenof. Here's a sample quote (in the threading area):
>
> ... the use of volatile accomplishes nothing but to prevent the
> compiler from making useful and desirable optimizations, providing
> no help whatsoever in making code "thread safe".
>
> Dave Butenhof, comp.programming.threads (1997-07-03)
>
> <http://groups.google.com/group/comp.programming.threads/msg/bd2cb64e70c9d155>
I do not think that signal handlers are perfectly analogous to
threads, although I will not deny that as both are examples of
asynchronous behavior, they are certainly related.
The issue at hand, as I understand it, is not even the general
behavior of signals. It is the behavior of fatal signals. That
is, a the program terminates without ever returning from the
signal handler. This is much simpler than the general problem of
synchronizing many threads. It is a little like a single thread
that runs for a while, then switches to another thread a single
time, and then both threads terminate.
>> 5.1.2.3p5 talks about the type of an object, with no
>> reference to how the object was defined:
>>
>> The least requirements on a conforming implementation are:
>>
>> - At sequence points, volatile objects are stable in the
>> ^^^^^^^^^^^^^^^^
>> sense that previous accesses are complete and subsequent
>> accesses have not yet occurred.
>
> As I understand it, under your interpretation this signal handler:
>
> #include <stdio.h>
> #include <signal.h>
> sig_atomic_t x;
> void handler (int sig) { sig_atomic_t volatile *p = &x; *p = 0; }
>
> int main (void)
> {
> signal (SIGINT, handler);
> x = 1;
> getchar ();
> return x;
> }
>
> always has well-defined behavior, since the signal handler simply
> stores 0 into a sig_atomic_t volatile object and it's immaterial how
> the object was defined. So if a signal arrives during the call to
> getchar, then 'main' must return 0 and not 1.
>
> But this interpretation doesn't correspond to how compilers behave.
> If the type sig_atomic_t is plain 'int', for example, a compiler is
> entitled to cache other references to x's contents even in the
> presence of signals. Both GCC and Sun C do this, e.g., on 64-bit
> SPARC they don't bother to set 'x' before getchar returns. More
> generally, I don't see how an object can be both volatile and
> nonvolatile at the same time: it has to be one or the other. Yet
> lvalues of both kinds can exist simultaneously.
I won't make a claim that the signal handler in the above code is
guaranteed to see 1 if called during getchar, because the
assignment in main does not access a volatile object.
However, I believe that if the assignment in main were changed to
the following, then the signal handler would be guaranteed to see
1 in x if the signal arrived in getchar;
*(sig_atomic_t volatile *) &x = 1;
To me, this is exactly what the C99 rationale is saying in 6.7.3,
toward the end:
If it is necessary to access a non-volatile object using
volatile semantics, the technique is to cast the address of
the object to the appropriate pointer-to-qualified type,
then dereference that pointer.
With the cast, `x' is accessed as a volatile object, because it
is accessed through a volatile lvalue. This is consistent with
the definitions of "object" and "lvalue" in the standard (and that
is why I quoted their definitions earlier).
> I suspect that I am simply misunderstanding your argument (which is
> not uncommon in this area!). If so, then if you could flesh out the
> argument a bit, that might help. (But I should warn you that I've
> never yet understood "volatile", despite my asking some very bright
> people what it actually means. :-)
I am not confident that I understand volatile correctly, either,
but I do want to help. I hope that my comments can clarify,
rather than throw additional mud on already muddy ground.
Maybe I am not being helpful because I misunderstood your
original objection. Perhaps all this is moot because Bruno's
module does not actually contain any casts to volatile.
> PS. MacLaren proposed a change to the C standard which would in his
> opinion fix some (but not all) of the problems with respect to signal
> handling and volatile; see
> <http://www.davros.org/c/public/pcuk0097.txt>.
> However, this proposal was not accepted.
I was aware that there had been a proposal, but not of the
details. Thanks for the pointer (and for the Open Group version
too).
--
"But hey, the fact that I have better taste than anybody else in the
universe is just something I have to live with. It's not easy being
me."
--Linus Torvalds
