Re: Compiler Support for Ensuring that a Statement is Atomic

Discussion in 'C Programming' started by Boudewijn Dijkstra, Jan 18, 2010.

  1. Op Sat, 16 Jan 2010 01:52:21 +0100 schreef Datesfat Chicks
    <>:
    > This is slightly off-topic, as it involves implementation rather than
    > the C language.
    >
    > It frequently comes up in embedded systems that one wishes to ensure
    > that a C-language statement is atomic.


    For you maybe.

    > One might have available functions or macros to disable or enable
    > interrupts, so one might write:
    >
    > volatile int sempahore;
    >
    > DI();
    > sempahore++;
    > EI();


    Imagine how a program with DI/EI all over the place can wreak havoc on
    your worst-case interrupt latency.

    > Whether an increment can be handled atomically depends on the processor,
    > where in memory the variable is located, its size, and on specific
    > decisions the compiler makes.
    >
    > Other operations that one might wish to ensure atomicity with include
    > assignments, bitfield assignments, tests, etc.
    >
    > For example, in the code:
    >
    > volatile unsigned long x;
    >
    > if (x > 29204) ...
    >
    > there might be a problem because an asynchronous process may update the
    > variable and cause the test to get inconsistent bytes as it performs the
    > test.


    Don't do that then. Use an OS service that ensures exclusive data
    ownership, like a messaging interface.

    > In most cases, one can protect the statements of concern with DI()/EI()
    > or find a way to guarantee atomicity. The issue is that this method of
    > protection can be inefficient. It consumes memory, consumes CPU cycles,
    > and affects the timing of interrupts.
    >
    > Here is my question:
    >
    > Has anyone seen any compilers that support guaranteeing that a certain
    > statement or test is atomic?


    No.

    > What I'd be looking for is something like:
    >
    > #pragma ASSERT_ATOMIC_STATEMENT_START
    > semaphore++;
    > #pragma ASSERT_ATOMIC_STATEMENT_END
    >
    > The pragmas would advise the compiler to:
    >
    > a)Try to compile the statement atomically (using a single instruction),
    > and


    Assuming that the architecture guarantees that any instruction so
    generated is atomic.

    > b)Create an error if it can't be compiled atomically.


    And then what? Try a different compiler? Switch architectures? Redesign
    the software?

    > This would save the expense of DI()/EI(), or generate an error if the
    > statement can't be compiled atomically.
    >
    > Is there anything like this in the world?
    >
    > Thanks, Datesfat



    --
    Gemaakt met Opera's revolutionaire e-mailprogramma:
    http://www.opera.com/mail/
    (remove the obvious prefix to reply by mail)
    Boudewijn Dijkstra, Jan 18, 2010
    #1
    1. Advertising

  2. Boudewijn Dijkstra wrote:
    > Op Sat, 16 Jan 2010 01:52:21 +0100 schreef Datesfat Chicks
    > <>:
    >> This is slightly off-topic, as it involves implementation rather than
    >> the C language.
    >>
    >> It frequently comes up in embedded systems that one wishes to ensure
    >> that a C-language statement is atomic.

    >
    > For you maybe.


    For me, too, although only occasionally, not "frequently". But then I
    don't spend much time programming in C.

    >> One might have available functions or macros to disable or enable
    >> interrupts, so one might write:
    >>
    >> volatile int sempahore;
    >>
    >> DI();
    >> sempahore++;
    >> EI();

    >
    > Imagine how a program with DI/EI all over the place can wreak havoc on
    > your worst-case interrupt latency.


    The effect on the worst-case interrupt latency does not depend on the
    number of DI/EI pairs "all over" the program, nor on how often they are
    executed. It depends only on the duration of the DI/EI pair that has the
    most code between the DI and the EI, in terms of the execution time of
    that code.

    But why do you, Boudewijn, criticize Datesfat for mentioning DI/EI, when
    Datesfat's very aim is to *avoid* DI/EI by making the compiler use an
    instruction that is intrinsically atomic?

    > Don't do that then. Use an OS service that ensures exclusive data
    > ownership, like a messaging interface.


    Such OS services tend to have longer interrupt-disabled regions than a
    simple "semaphore++" and thus more effect on the worst-case latency. And
    then we have the bare-board systems that use just background +
    interrupts with no OS to speak of. Finally, Datesfat's question and
    proposal are also applicable to the internals of OS services, which also
    could benefit from using intrinsically atomic instructions instead of DI/EI.

    --
    Niklas Holsti
    Tidorum Ltd
    niklas holsti tidorum fi
    . @ .
    Niklas Holsti, Jan 18, 2010
    #2
    1. Advertising

  3. Op Mon, 18 Jan 2010 10:04:56 +0100 schreef Niklas Holsti
    <>:
    > Boudewijn Dijkstra wrote:
    >> Op Sat, 16 Jan 2010 01:52:21 +0100 schreef Datesfat Chicks
    >> <>:


    >>> One might have available functions or macros to disable or enable
    >>> interrupts, so one might write:
    >>>
    >>> volatile int sempahore;
    >>>
    >>> DI();
    >>> sempahore++;
    >>> EI();

    >> Imagine how a program with DI/EI all over the place can wreak havoc on
    >> your worst-case interrupt latency.

    >
    > The effect on the worst-case interrupt latency does not depend on the
    > number of DI/EI pairs "all over" the program, nor on how often they are
    > executed. It depends only on the duration of the DI/EI pair that has the
    > most code between the DI and the EI, in terms of the execution time of
    > that code.


    Right. But every DI/EI pair does increase _average_ interrupt latency,
    for all interrupts, so even those that might be really important and
    cannot even access that particular piece of shared data.

    > But why do you, Boudewijn, criticize Datesfat for mentioning DI/EI, when
    > Datesfat's very aim is to *avoid* DI/EI by making the compiler use an
    > instruction that is intrinsically atomic?


    I merely intended to point out a disadvantage of using DI/EI (which
    horribly failed). In fact, in the context of his question, the widely
    used DI/EI is very illustrative and it would be unwise to not mention it.



    --
    Gemaakt met Opera's revolutionaire e-mailprogramma:
    http://www.opera.com/mail/
    (remove the obvious prefix to reply by mail)
    Boudewijn Dijkstra, Jan 19, 2010
    #3
    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. David
    Replies:
    0
    Views:
    299
    David
    May 2, 2004
  2. Simon
    Replies:
    3
    Views:
    811
    Simon Harvey
    May 26, 2004
  3. Peter Hardy

    Ensuring users have provided valid html

    Peter Hardy, Dec 29, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    318
    Peter Hardy
    Dec 29, 2004
  4. Mr. C
    Replies:
    3
    Views:
    268
    James Dow Allen
    Jan 21, 2010
  5. Charles Oliver Nutter

    [ANN] atomic 0.0.1 - An atomic reference for Ruby

    Charles Oliver Nutter, Jun 8, 2010, in forum: Ruby
    Replies:
    5
    Views:
    210
    Robert Dober
    Jun 8, 2010
Loading...

Share This Page