sig_atomic_t

Discussion in 'C Programming' started by j0mbolar, Nov 6, 2004.

  1. j0mbolar

    j0mbolar Guest

    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.
     
    j0mbolar, Nov 6, 2004
    #1
    1. Advertising

  2. j0mbolar

    Chris Torek Guest

    In article <news:>
    j0mbolar <> wrote:
    >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.)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Nov 6, 2004
    #2
    1. Advertising

  3. j0mbolar

    Dan Pop Guest

    In <> (j0mbolar) writes:

    >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
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Currently looking for a job in the European Union
     
    Dan Pop, Nov 9, 2004
    #3
  4. j0mbolar

    Eric Sosman Guest

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

    --
     
    Eric Sosman, Nov 9, 2004
    #4
  5. j0mbolar

    Dan Pop Guest

    In <cmr8ld$dnn$> Eric Sosman <> writes:

    >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, 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
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Currently looking for a job in the European Union
     
    Dan Pop, Nov 10, 2004
    #5
  6. j0mbolar

    Eric Sosman Guest

    Dan Pop wrote:
    > In <cmr8ld$dnn$> Eric Sosman <> writes:
    >
    >>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.

    --
     
    Eric Sosman, Nov 10, 2004
    #6
  7. j0mbolar

    Dan Pop Guest

    In <cmtcj3$fle$> Eric Sosman <> writes:

    >Dan Pop wrote:
    >> In <cmr8ld$dnn$> Eric Sosman <> writes:
    >>
    >>>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
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
    Currently looking for a job in the European Union
     
    Dan Pop, Nov 10, 2004
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Vijay Kumar R Zanvar

    sig_atomic_t

    Vijay Kumar R Zanvar, Nov 24, 2003, in forum: C Programming
    Replies:
    6
    Views:
    1,043
    Chris Torek
    Nov 29, 2003
  2. Mark Piffer

    typdef'ing from sig_atomic_t valid?

    Mark Piffer, Apr 22, 2004, in forum: C Programming
    Replies:
    21
    Views:
    1,927
    Dan Pop
    Apr 29, 2004
  3. Ian Pilcher

    Is "volatile sig_atomic_t" redundant?

    Ian Pilcher, Mar 24, 2005, in forum: C Programming
    Replies:
    14
    Views:
    1,227
    Tor Rustad
    Mar 29, 2005
  4. Ben Pfaff

    Re: Minimum width of sig_atomic_t?

    Ben Pfaff, Jan 28, 2010, in forum: C Programming
    Replies:
    0
    Views:
    386
    Ben Pfaff
    Jan 28, 2010
  5. Ersek, Laszlo

    Re: Minimum width of sig_atomic_t?

    Ersek, Laszlo, Jan 28, 2010, in forum: C Programming
    Replies:
    0
    Views:
    579
    Ersek, Laszlo
    Jan 28, 2010
Loading...

Share This Page