sig_atomic_t

J

j0mbolar

how is atomicity guaranteed on say a 32 bit architecture?
or a pentium? because doesn't sig_atomic_t have to
be an alias for a type that is the smallest unit
(a signed char or unsigned char)? if so, then on a 32 bit
architecture, and where char is 8 bits, you can't get
atomicity, can you? and does this mean sig_atomic_t is
useless? if not, then what type of magic would be implemented
to guarantee such an atomic write? It doesn't seem possible.
 
C

Chris Torek

how is atomicity guaranteed on say a 32 bit architecture?
or a pentium? because doesn't sig_atomic_t have to
be an alias for a type that is the smallest unit
(a signed char or unsigned char)?

First, no, sig_atomic_t does *not* have to be the *smallest*
type.

Second, sig_atomic_t does not have to be atomic, either. It only
has to be "atomic" with respect to simple assignments to variables
of type "volatile sig_atomic_t" in signal handlers. This is quite
a different proposition than atomicity with respect to CPU<->memory
and/or bus-level transactions.

Note in particular:

volatile sig_atomic_t sig_var; /* OK so far */

void sig_handler(int sig) {
sig_var++; /* DANGER */
...
}

The effect of this "sig_var++" operation is *not* required to be
atomic with respect to signal handlers. You *can* do something
like this:

void sig_handler(int sig) {
sig_var = 1; /* OK */
...
}

because it is a simple assignment, not a "read existing value,
compute value+1, schedule write of new value back" sequence. (The
latter is not atomic on any load/store architecture that lacks
"increment memory" instructions. On multiprocessor load/store
systems, one generally has something like "compare and swap" or
"load linked/store conditional" from which to build atomic operations.
I have written about these before -- use google search if you want
more information.)
 
D

Dan Pop

In said:
how is atomicity guaranteed on say a 32 bit architecture?
or a pentium?

The "or" doesn't make any sense, Pentium being a 32-bit architecture it
is already included in the first question.
because doesn't sig_atomic_t have to
be an alias for a type that is the smallest unit
(a signed char or unsigned char)?

Definitely NOT! There are systems that do not support byte accesses in
hardware. Storing a byte on such systems is far from what most of us
would consider an atomic operation.
if so, then on a 32 bit
architecture, and where char is 8 bits, you can't get
atomicity, can you? and does this mean sig_atomic_t is
useless?

sig_atomic_t is perfectly useful, on each conforming implementation, for
the purpose documented in the standard.
if not, then what type of magic would be implemented
to guarantee such an atomic write? It doesn't seem possible.

Note that sig_atomic_t only guarantees atomicity of store operations
against another part of the same program (e.g. the main code is
interrupted by a signal handler or a signal handler is interrupted
by another signal handler). This can be trivially achieved by choosing
the integer type reflecting the size of the machine word. Even on a
hypothetical system where the machine word is less than one byte, the
compiler can still guarantee the atomicity of the store operations on
sig_atomic_t objects by disabling the interrupts during the duration of
the store operation.

Although the standard doesn't say so (it tries to, without quite
succeeding), it is highly advisable that reading a sig_atomic_t value
is also an atomic operation.

Dan
 
E

Eric Sosman

Dan said:
[...]
Note that sig_atomic_t only guarantees atomicity of store operations
against another part of the same program [...]

Although the standard doesn't say so (it tries to, without quite
succeeding), it is highly advisable that reading a sig_atomic_t value
is also an atomic operation.

The Standard says that a sig_atomic_t can be *accessed*
atomically (7.14, paragraph 2). The "write-only" language
of 7.14.1.1/5 applies only to operations within certain
signal handlers, but does not restrict what can occur
elsewhere in the program.

I'm at a loss to understand why the Standard says it's
undefined for such a signal handler to read a sig_atomic_t.
The Rationale tells us that "The C89 Committee concluded that
about the only thing a strictly conforming program can do in
a signal handler is to assign a value ..." but doesn't explain
why the Committee felt that reading a value would be a problem.
I speculate that they couldn't think of anything useful a
handler could do with a value it managed to read, but it seems
out of character for the Standard to legislate against useless
code for no (apparent) reason. One of those mysteries, I guess.
 
D

Dan Pop

In said:
Dan said:
[...]
Note that sig_atomic_t only guarantees atomicity of store operations
against another part of the same program [...]

Although the standard doesn't say so (it tries to, without quite
succeeding), it is highly advisable that reading a sig_atomic_t value
is also an atomic operation.

The Standard says that a sig_atomic_t can be *accessed*
atomically (7.14, paragraph 2).

Since sig_atomic_t doesn't mean anything useful without the volatile
qualifier, 7.14, paragraph 2 is worth exactly zilch, because of 6.7.3p6:

What constitutes an access to an object that has
volatile-qualified type is implementation-defined.
The "write-only" language
of 7.14.1.1/5 applies only to operations within certain
signal handlers, but does not restrict what can occur
elsewhere in the program.

The "write-only" language from 7.14.1.1/5 is the only *real* clue provided
by the standard about the usage of volatile sig_atomic_t objects that are
shared between the main C program and signal handlers. Of course, you
can do anything you want with sig_atomic_t objects that aren't accessed
by signal handlers, but why would you want to use this type in a signal
handler-free context?
I'm at a loss to understand why the Standard says it's
undefined for such a signal handler to read a sig_atomic_t.
The Rationale tells us that "The C89 Committee concluded that
about the only thing a strictly conforming program can do in
a signal handler is to assign a value ..." but doesn't explain
why the Committee felt that reading a value would be a problem.
I speculate that they couldn't think of anything useful a
handler could do with a value it managed to read, but it seems
out of character for the Standard to legislate against useless
code for no (apparent) reason. One of those mysteries, I guess.

It's far from useless. How do you detect that your signal handler is
interrupting the execution of another signal handler without reading
a sig_atomic_t?

Dan
 
E

Eric Sosman

Dan said:
In said:
Dan said:
[...]
Note that sig_atomic_t only guarantees atomicity of store operations
against another part of the same program [...]

Although the standard doesn't say so (it tries to, without quite
succeeding), it is highly advisable that reading a sig_atomic_t value
is also an atomic operation.

The Standard says that a sig_atomic_t can be *accessed*
atomically (7.14, paragraph 2).

Since sig_atomic_t doesn't mean anything useful without the volatile
qualifier, 7.14, paragraph 2 is worth exactly zilch [...]

It is easy to prove that "The Standard doesn't
say X" for any X whatsoever, if one is permitted to
ignore those parts of the Standard that embarrass
the argument.
 
D

Dan Pop

In said:
Dan said:
In said:
Dan Pop wrote:

[...]
Note that sig_atomic_t only guarantees atomicity of store operations
against another part of the same program [...]

Although the standard doesn't say so (it tries to, without quite
succeeding), it is highly advisable that reading a sig_atomic_t value
is also an atomic operation.

The Standard says that a sig_atomic_t can be *accessed*
atomically (7.14, paragraph 2).

Since sig_atomic_t doesn't mean anything useful without the volatile
qualifier, 7.14, paragraph 2 is worth exactly zilch [...]

It is easy to prove that "The Standard doesn't
say X" for any X whatsoever, if one is permitted to
ignore those parts of the Standard that embarrass
the argument.

Could you be more specific, please? What part of the standard suppresses
6.7.3p6 in the context of sig_atomic_t? And if it still applies, what
relevant parts of the standard have I ignored?

Dan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,479
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top