[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#5248) non-atomic signal variables
[rearranging]
Howard Chu writes:
> The C standard defines "int" to be the most efficient machine word,
> and that is always atomic.
It does neither, that I can see. Among other things because "most
efficient" is not well-defined. E.g. by space or time? Efficient with
which operations? It's the recommended intent somewhere (the
Rationale?), but that must be subject to whatever other restrictions an
implementor faces. (16+ bits, backwards compatibility, etc.)
And the compiler can choose between an atomic and non-atomic operation,
even with volatile. Volatile guarantees a change is complete at a
sequence point. Signals need not arrive at sequence points. (C99
5.1.2.3p2,4. You can download the standard with amendments free at
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>.)
Otherwise the standard would not have needed to define sig_atomic_t.
> sig_atomic_t is irrelevant in slapcat. Whether we detect zero/non-zero
> immediately, one entry, or two entries after the signal occurs isn't
> going to make any difference.
Well, I don't see any reason not to use it when the standard says so and
the change is trivial, even if we don't know of a real-life failure.
(E.g. if the compiler detects that the variable will not legally change
and optimizes it away, or if it is being read during a signal which
changes it so the result of the non-atomic read is a trap
representation.)
> Likewise, there's no issue with gotintr/abcan. The signal handler
> isn't armed until the writes are complete. Therefore whether it can be
> read atomically or not inside the handler is irrelevant, the value is
> constant.
So reading abcan is safe, but reading gotintr is not. Read first half
before signal as 0, last half as -1. Then the switch on it fails.
--
Hallvard