Is "volatile sig_atomic_t" redundant?

[Ian Pilcher]

It's pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;

C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
type of an object that can be accessed as an atomic entity, even in the
presence of asynchronous interrupts."

Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)

TIA

--
================================================== ======================
Ian Pilcher i.*******@comcast.net
================================================== ======================

[Andrey Tarasevich]

Ian Pilcher wrote:

It's pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;

C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
type of an object that can be accessed as an atomic entity, even in the
presence of asynchronous interrupts."

Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)
...

Firstly, 'sig_atomic_t' doesn't mean "thread atomic". 'sig_atomic_t' is
a significantly weaker guarantee.

Secondly, declaring an object as 'volatile' doesn't make it atomic.
'volatile' doesn't have anything to do with atomicity. It just disables
certain optimizations. In order to ensure thread-atomicity the program
has to use additional platform-specific constructs.

--
Best regards,
Andrey Tarasevich

[Ian Pilcher]

Andrey Tarasevich wrote:

Firstly, 'sig_atomic_t' doesn't mean "thread atomic". 'sig_atomic_t' is
a significantly weaker guarantee.

Secondly, declaring an object as 'volatile' doesn't make it atomic.
'volatile' doesn't have anything to do with atomicity. It just disables
certain optimizations. In order to ensure thread-atomicity the program
has to use additional platform-specific constructs.

Huh?

--
================================================== ======================
Ian Pilcher i.*******@comcast.net
================================================== ======================

[Walter Roberson]

In article <FL********************@comcast.com>,
Ian Pilcher <i.*******@comcast.net> wrote:

It's pretty common to see declarations such as: static volatile sig_atomic_t caught_signal = 0; C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
type of an object that can be accessed as an atomic entity, even in the
presence of asynchronous interrupts." Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)

volatile tells the compiler that the value may have changed
between references, so that, for example,

a = (int) caught_signal;
b = (int) caught_signal;

is not necessarily going to be the same as

a = b = (int) caught_signal;

because there might have been a signal between the two.

sig_atomic_t is something that can be read by the processor in one
go, even in the presence of interrupts. For example, if you had

volatile double var;

then on -some- processors there is the possibility that the processor
might read the first 4 bytes of the double, get interrupted and
suspend the read half-way through, and pick up the read again later,
after the signal has overwritten the double... leaving you with
half the old value and half the new value.

This topic gets into processor dependant matters about whether or
what operations get restarted under what conditions, which can be
influenced by the POSIX sigaction(), and can be influenced by
very OS dependant routines such as SGI's IRIX handle_sigfpes(). But
no matter how the processor handles such things, sig_atomic_t is
something that you can be sure will not end up with corrupted bytes
due to interrupts, cache coherency matters and so on.
What gets even more interesting is if you have an element
similar to sig_atomic_t in which one is guaranteed that basic
arithmetic operations such as "increment by one" or "decrement
by one" will be done without interruption, even if it requires
a special processor instruction to do so. If you can be sure
of being able to do var++ and var-- without interrupts, then you can
impliment semaphores without having to drop into a driver routine
that raises high-level masks or priorities to guard the transaction.

Notice what you quoted said "accessed": to do semaphores, you
have to go beyond just read/writes into at least one read-modify-write
atomic instruction.
--
Oh, to be a Blobel!

[Andrey Tarasevich]

Ian Pilcher wrote:

...

Firstly, 'sig_atomic_t' doesn't mean "thread atomic". 'sig_atomic_t' is
a significantly weaker guarantee.

Secondly, declaring an object as 'volatile' doesn't make it atomic.
'volatile' doesn't have anything to do with atomicity. It just disables
certain optimizations. In order to ensure thread-atomicity the program
has to use additional platform-specific constructs.

Huh?

What "huh"?

--
Best regards,
Andrey Tarasevich

[Dave Vandervies]

In article <FL********************@comcast.com>,
Ian Pilcher <i.*******@comcast.net> wrote:

It's pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;

C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
type of an object that can be accessed as an atomic entity, even in the
presence of asynchronous interrupts."

Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)

The description of signal handling specifically states that a signal
handler is allowed to assign a value to a volatile sig_atomic_t; a
non-volatile sig_atomic_t is included in the "anything else" that invokes
undefined behavior. So to be able to store a value in the signal handler
and be guaranteed to see the change in non-sighandler code, you need to
be storing it into an object with the volatile qualifier.

(Given that, I'm not sure what the point of the "(possibly volatile-
qualified)" in the definition of sig_atomic_t is.)

In practice, if the sig_atomic_t type isn't volatile-qualified (which
is permitted) and the sig_atomic_t object you're using as your flag also
isn't volatile-qualified, code like this:
--------
while(!caught_signal)
{
/*do stuff*/
}
--------
is likely to get optimized to check-once-and-loop-forever, so even if
the signal handler sets the flag the non-sighandler code won't see the
change as intended.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I cannot conceive of a legitimate use for the result.
I can conceive of several illegitimacies.
--CBFalconer in comp.lang.c

[Dave Vandervies]

In article <11*************@news.supernews.com>,
Andrey Tarasevich <an**************@hotmail.com> wrote:

Ian Pilcher wrote:

It's pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;

C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
type of an object that can be accessed as an atomic entity, even in the
presence of asynchronous interrupts."

Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)
...

Firstly, 'sig_atomic_t' doesn't mean "thread atomic". 'sig_atomic_t' is
a significantly weaker guarantee.

Secondly, declaring an object as 'volatile' doesn't make it atomic.
'volatile' doesn't have anything to do with atomicity. It just disables
certain optimizations. In order to ensure thread-atomicity the program
has to use additional platform-specific constructs.

Yes. And? What did his question have to do with thread-atomicity?

(It's worth noting, though, that one common implementation handles
asynchronous signals by creating a thread running the appropriate handler,
and that (on that implementation) sighandler-atomic is therefore the
same thing as thread-atomic.)
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I cannot conceive of a legitimate use for the result.
I can conceive of several illegitimacies.
--CBFalconer in comp.lang.c

[Ian Pilcher]

Dave Vandervies wrote:

The description of signal handling specifically states that a signal
handler is allowed to assign a value to a volatile sig_atomic_t; a
non-volatile sig_atomic_t is included in the "anything else" that invokes
undefined behavior. So to be able to store a value in the signal handler
and be guaranteed to see the change in non-sighandler code, you need to
be storing it into an object with the volatile qualifier.
Serves me right for not reading the next section.
(Given that, I'm not sure what the point of the "(possibly volatile-
qualified)" in the definition of sig_atomic_t is.)

I'm not sure either. Maybe it has something to do with threads. ;-)

Thanks!

--
================================================== ======================
Ian Pilcher i.*******@comcast.net
================================================== ======================

[Andrey Tarasevich]

Dave Vandervies wrote:

...

It's pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;

C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
type of an object that can be accessed as an atomic entity, even in the
presence of asynchronous interrupts."

Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)
...

Firstly, 'sig_atomic_t' doesn't mean "thread atomic". 'sig_atomic_t' is
a significantly weaker guarantee.

Secondly, declaring an object as 'volatile' doesn't make it atomic.
'volatile' doesn't have anything to do with atomicity. It just disables
certain optimizations. In order to ensure thread-atomicity the program
has to use additional platform-specific constructs.

Yes. And? What did his question have to do with thread-atomicity?
...

Well, I might've misinterpreted the OP's question. We are taking about
third-party code and I assumed that the presence of [indeed redundant]
'volatile' means that the code is intended to work in multithreaded
environment. My assumption could be incorrect. Or it could be correct,
since, once again, we are talking about third-party code.

--
Best regards,
Andrey Tarasevich

[Michael Mair]

Andrey Tarasevich wrote:

Ian Pilcher wrote:

...

Firstly, 'sig_atomic_t' doesn't mean "thread atomic". 'sig_atomic_t' is
a significantly weaker guarantee.

Secondly, declaring an object as 'volatile' doesn't make it atomic.
'volatile' doesn't have anything to do with atomicity. It just disables
certain optimizations. In order to ensure thread-atomicity the program
has to use additional platform-specific constructs.

Huh?

What "huh"?

The OP asked whether the "volatile" in
static volatile sig_atomic_t somevar;
is redundant as sig_atomic_t might be typedefed as
typedef volatile sometype sig_atomic_t
according to the C99 standard if I remember and understand
correctly.

You tell him some interesting though (from my point of view
and obviously his, too) rather unrelated things about
atomicity which do not answer his original question (even
though they may answer the question you think stands behind
the original question).
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Andrey Tarasevich]

Michael Mair wrote:

...

Firstly, 'sig_atomic_t' doesn't mean "thread atomic". 'sig_atomic_t' is
a significantly weaker guarantee.

Secondly, declaring an object as 'volatile' doesn't make it atomic.
'volatile' doesn't have anything to do with atomicity. It just disables
certain optimizations. In order to ensure thread-atomicity the program
has to use additional platform-specific constructs.

Huh?

What "huh"?

The OP asked whether the "volatile" in
static volatile sig_atomic_t somevar;
is redundant as sig_atomic_t might be typedefed as
typedef volatile sometype sig_atomic_t
according to the C99 standard if I remember and understand
correctly.

But his original message does not include that second part "[...] as
sig_atomic_t might be typedef-ed as [...]". It was Dave who mentioned
this in his message. The OP's original question boiled down to whether
'volatile sig_atomic_t' is redundant. He did not specify the context and
which kind of atomicity he had in mind.

For signal-atomicity, this 'volatile', I agree, is redundant (if we
forget for a moment about that little detail mentioned by Dave, which
appears to be a slightly defective wording in the standard).

For thread-atomicity it is not redundant. The OP was talking about
third-party code. Since I don't know the intent of the authors of the
code, I suggested that it is possible that they were potentially aiming
at thread-atomicity.

--
Best regards,
Andrey Tarasevich

[Dave Vandervies]

In article <11*************@news.supernews.com>,
Andrey Tarasevich <an**************@hotmail.com> wrote:

Michael Mair wrote:

The OP asked whether the "volatile" in
static volatile sig_atomic_t somevar;
is redundant as sig_atomic_t might be typedefed as
typedef volatile sometype sig_atomic_t
according to the C99 standard if I remember and understand
correctly.

But his original message does not include that second part "[...] as
sig_atomic_t might be typedef-ed as [...]". It was Dave who mentioned
this in his message. The OP's original question boiled down to whether
'volatile sig_atomic_t' is redundant. He did not specify the context and
which kind of atomicity he had in mind.

From the OP:
}C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}type of an object that can be accessed as an atomic entity, even in the
}presence of asynchronous interrupts."

This was the redundancy to which he was referring - if the typedef
itself is volatile-qualified (which C99 says is possible), is a volatile
qualifier for objects of that type redundant?

For signal-atomicity, this 'volatile', I agree, is redundant (if we
forget for a moment about that little detail mentioned by Dave, which
appears to be a slightly defective wording in the standard).
For signal-atomicity, yes, because volatile has nothing to do with
atomicity.
But for it to be *useful*, it needs to be volatile, to guarantee that
changes will show up in non-sighandler code after the signal handler runs.

For thread-atomicity it is not redundant.
For thread-atomicity, sig_atomic_t is almost completely useless, volatile
or not; if you have enough knowledge of the implementation's thread
handling to know whether it gives you anything that's worth having,
you have enough knowledge of the implementation's thread handling to
not need it.
The OP was talking about
third-party code.
What third-party code? The OP was talking about a common idiom and the
definitions in C99.

Since I don't know the intent of the authors of the
code, I suggested that it is possible that they were potentially aiming
at thread-atomicity.

Have you ever written code that used a signal handler?
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I cannot conceive of a legitimate use for the result.
I can conceive of several illegitimacies.
--CBFalconer in comp.lang.c

[Andrey Tarasevich]

Dave Vandervies wrote:

...

The OP asked whether the "volatile" in
static volatile sig_atomic_t somevar;
is redundant as sig_atomic_t might be typedefed as
typedef volatile sometype sig_atomic_t
according to the C99 standard if I remember and understand
correctly.
But his original message does not include that second part "[...] as
sig_atomic_t might be typedef-ed as [...]". It was Dave who mentioned
this in his message. The OP's original question boiled down to whether
'volatile sig_atomic_t' is redundant. He did not specify the context and
which kind of atomicity he had in mind.

From the OP:
}C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
}type of an object that can be accessed as an atomic entity, even in the
}presence of asynchronous interrupts."

This was the redundancy to which he was referring - if the typedef
itself is volatile-qualified (which C99 says is possible), is a volatile
qualifier for objects of that type redundant?

OK, I might need a new pair of glasses :)

For signal-atomicity, this 'volatile', I agree, is redundant (if we
forget for a moment about that little detail mentioned by Dave, which
appears to be a slightly defective wording in the standard).

For signal-atomicity, yes, because volatile has nothing to do with
atomicity.
But for it to be *useful*, it needs to be volatile, to guarantee that
changes will show up in non-sighandler code after the signal handler runs.

I assumed that the intent of the wording used in the standard is to
require that declaring an object as just 'sig_atomic_t' (no 'volatile')
is sufficient to ensure its usability. In other words, if some
implementation needs 'sig_atomic_t' objects to be declared as 'volatile'
for the changes to show in non-sighandler code, then this implementation
shall define 'sig_atomic_t' as a volatile-qualified type. Now I see that
this is not explicitly required. The fact that 7.14.1/5 refers to
'volatile sig_atomic_t' suggests that my assumption was wrong.

The OP was talking about
third-party code.

What third-party code? The OP was talking about a common idiom and the
definitions in C99.

He said

************************************************** ************
It's pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;
************************************************** ************

That's what I refer to as "talking about third-party code".

Since I don't know the intent of the authors of the
code, I suggested that it is possible that they were potentially aiming
at thread-atomicity.

Have you ever written code that used a signal handler?

Yes I have. And?

--
Best regards,
Andrey Tarasevich

[Dave Vandervies]

In article <11*************@news.supernews.com>,
Andrey Tarasevich <an**************@hotmail.com> wrote:

Dave Vandervies wrote:

...

The OP was talking about
third-party code.

What third-party code? The OP was talking about a common idiom and the
definitions in C99.

He said

************************************************* *************
It's pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;
************************************************* *************

That's what I refer to as "talking about third-party code".

No, that's presenting an example of a common idiom, to introduce a
question about that idiom.

Since I don't know the intent of the authors of the
code, I suggested that it is possible that they were potentially aiming
at thread-atomicity.

Have you ever written code that used a signal handler?

Yes I have. And?

Not immediately recognizing that the intent of a declaration that
contains "volatile sig_atomic_t" is to provide a flag that can be set
in an asynchronous signal handler doesn't exactly inspire confidence in
your ability to comment intelligently on it.
dave

--
Dave Vandervies dj******@csclub.uwaterloo.ca
I cannot conceive of a legitimate use for the result.
I can conceive of several illegitimacies.
--CBFalconer in comp.lang.c

[Tor Rustad]

"Ian Pilcher" <i.*******@comcast.net> wrote in message

It's pretty common to see declarations such as:

static volatile sig_atomic_t caught_signal = 0;

C99 defines sig_atomic_t as a "... (possibly volatile-qualified) integer type of an object that can be accessed as an atomic entity, even in the presence of asynchronous interrupts."

Does this mean that the use of "volatile" in the above declaration is
redundant? (It sure sounds that way to me.)

Yes, for implementations that has sig_atomic_t typedef like e.g.:

typedef volatile int sig_atomic_t;

since you anyway need the definition

static volatile sig_atomic_t caught_signal = 0;

if you want to update "caught_signal" in a signal handler.

--
Tor <torust AT online DOT no>