Ada Programming/Pragmas/Atomic

Computing » Computer Science » Computer Programming » Ada Programming

---

pragma Atomic (local_name);

Description

Atomic is a representation pragma that can be used with types and variables to specify that the code generated must read and write the type or variable from memory atomically, i.e. as a single/non-interruptible operation. It implies pragma Volatile, the difference is that pragma Atomic is stronger: the compilation must fail if the variable cannot be updated atomically.

This is typically used in the context of interfacing with hardware registers, which must be written atomically and where the compiler must not reorder or suppress any redundant read or write. In some cases it can also be used for tasking, but for communication of Ada tasks it is safer to use protected types or other synchronization primitives.

Example

Device_Status : Status_Register;
pragma Atomic (Device_Status);
for Device_Status'Address use [[Ada Programming/Libraries/|]].System.Storage_Elements.To_Address (16#8010_FF74#);

Incorrect usage

It is almost always incorrect to use atomic or volatile variables for tasking. When an object is atomic it just means that it will be read from or written to memory atomically. The compiler will not generate atomic instructions or memory barriers when accessing to that object, it will just:

• check that the architecture guarantees atomic memory loads and stores,
• disallow some compiler optimizations, like reordering or suppressing redundant accesses to the object.

For example, the following code, where A is an atomic object can be misunderstood:

A := A + 1;  -- Not an atomic increment!

The compiler will not (and is not allowed by the Standard to) generate an atomic increment instruction to directly increment and update from memory the variable A. This is the code generated by the compiler:

  A := A + 1;
804969f:	a1 04 95 05 08       	mov    0x8059504,%eax
80496a4:	40                   	inc    %eax
80496a5:	a3 04 95 05 08       	mov    %eax,0x8059504

As can be seen, no atomic increment instruction or test-and-set opcode will be generated. Like in other programming languages, if these specific instructions are required in the program they must be written explicitly using machine code insertions.

The above code snippet is equivalent to the following code (both code sequences generates exactly the same object code), where T is a (non-atomic) temporary variable:

T := A;      -- A is copied atomically to local variable T
T := T + 1;  -- local variable T is incremented
A := T;      -- A is stored atomically

Thus it is incorrect to modify an atomic variable at the same time from multiple tasks. For example, two tasks incrementing a counter in parallel. Even in an uniprocessor, other Ada tasking features like a protected object should be used instead. In multiprocessors, depending on the memory consistency model, using various atomic or volatile variables for task communication can have surprising consequences. Therefore, extreme care should be taken when using atomic objects for task data sharing or synchronization, specially in a multiprocessor.

Portability

Compilers

Atomic is a standard pragma since Ada 95, defined in the Systems Programming Annex (Annex C). This is a specialized needs annex, therefore this pragma is not available in those compilers not implementing that annex.

Ada versions

• Available in Ada 95 and Ada 2005.
• In Ada 83 pragma Shared produces similar effects than pragma Atomic (but it is obsolescent since Ada 95).

Platforms

Atomic is a portability aid between different platforms. For example, when porting between a 64-bit to a 32-bit architecture, the compiler will detect portability problems thanks to this pragma.

Interfacing

The effects of pragma Atomic can be achieved in C using the type volatile sig_atomic_t, defined in signal.h (called volatile std::sig_atomic_t in C++). It is worth noting that the only values that can be portably stored in this type are 0–127, whereas the Ada pragma doesn't impose any specific limit (other than the type of the atomic object).

However, this C type is rarely known by programmers. Therefore, the C volatile qualifier is the approach widely used both for volatile and atomic data, even if atomic access in required. Thus, when interfacing with existing C code, the programmer must first read the code to understand whether the data needs atomic load and stores or not. If needed, the data should be marked in the Ada side with pragma Atomic or Atomic_Components. Otherwise, pragma Volatile or Volatile_Components should be added instead.

C++11 and C11 incorporated atomic operations and types, but differ from the semantics in Ada and are not compatible.

See also

Wikibook

• Ada Programming
• Ada Programming/Pragmas
• Ada Programming/Pragmas/Volatile
• Ada Programming/Pragmas/Atomic Components
• Ada Programming/Pragmas/Volatile Components
• Ada Programming/Pragmas/Shared (obsolescent)

Ada Reference Manual

• C.6 Shared Variable Control (Annotated)

Ada 95 Rationale

• C.5 Shared Variable Control

Ada 95 Quality and Style Guide

• 6.2.4 Unprotected Shared Variables