Definition of "atomic object"

Question

In standard jargon of C and C++, the phrase "atomic object" means "object of atomic type," does it not?

No standard will explicitly define every two-word phrase, so one does not fault the C and C++ standards for omitting explicit definition of this one. Nevertheless, when I read in the C++17 standard (draft here), sect. 4.7.1(4), that "all modifications to a particular atomic object M occur in some particular total order, called the modification order of M"—and when the standard repeatedly employs similar language to delimit ever more precise logic for concurrency—I would like to be sure that I am not inadvertently misunderstanding.

Do I assume correctly that the phrase "atomic object" means

• object of atomic type?

The only plausible alternative I can imagine would be that the phrase instead meant

• properly aligned object small enough that hardware could handle it atomically.

Which is it, please?

(Note: I tag this question both C and C++ because, when it comes to atomics, the two standards use almost identical language. For this reason, an expert in either language can answer as far as I know. If for some reason I am mistaken, then please remove the C tag and retain the C++.)

Reference: see also this question, for which my question is preliminary.

Eyehole

Modern C and C++ have an atomic keyword, which is a type qualifier just like const. So I would assume atomic object means "an atomic-qualified object". That is, declared as (C11) _Atomic int blondie; with the _Atomic type qualifier. – Minium

@Minium C++ does not have an atomic keyword. – Bootblack

@Bootblack Well whatever, std::atomic<int> template fluff. – Minium

For C11, see: port70.net/~nsz/c/c11/n1570.html#6.2.5p20; port70.net/~nsz/c/c11/n1570.html#6.2.5p27; port70.net/~nsz/c/c11/n1570.html#6.2.6.1p9; port70.net/~nsz/c/c11/n1570.html#6.5.2.3p5; port70.net/~nsz/c/c11/n1570.html#6.5.2.4p2; port70.net/~nsz/c/c11/n1570.html#6.7.2.4; port70.net/~nsz/c/c11/n1570.html#6.7.3; Atomics <stdatomic.h>. And probably other places — there are lots of mentions of atomic in the standard linked to. C18 is very similar, though atomic figure in the changes. – Cyanic

Atomic object is not necessarily an object of std::atomic type (at least in C++20). New std::atomic_­ref class template makes an object it refers to atomic. … for the lifetime of the atomic_­ref object, the object referenced by *ptr is an atomic object. Whether such wording is optimal is another question. – Gatehouse

Answer 1

The C++ standard imposes a set of rules on operations and effects of operations on atomic objects ([intro.races]). If all operations on an object satisfy those rules, then that object is atomic.

the phrase "atomic object" means "object of atomic type," does it not?

It is not worded so in the standard. But since the effect of operations is determined by the type of the object, this is not an unreasonable conclusion. Also correspondingly: Atomic type is a type whose instances are atomic objects.

The C++ standard library provides a set of types which are guaranteed to be atomic, as well as functions for those types which are guaranteed to be atomic operations ([atomics]).

properly aligned object small enough that hardware could handle it atomically.

C++ standard specifies nothing about alignment or size of atomic objects.

If an object/type is guaranteed to be atomic (see [atomics]), and if the hardware has such requirements for atomicity, then either the implementation of the language must guarantee that those requirements are met, or the implementation must employ locks to enforce atomicity.

Bootblack

I can imagine an type that can change its atomicy during runtime. Not sure if thats a good thing to do, but usually they take very much care to not restrict generality in the standard when there is no need to. Maybe thats the reason there is no "atomic type" but only "atomic objects" – Archicarp

@user463035818 I suppose you could call such type conditionally atomic. There are atomic types, which are specified in [atomics] section. – Bootblack

@user463035818 This is probably why the member of std::atomic is named is_always_lock_free. Also note: "Atomic types are also allowed to be sometimes lock-free, e.g. if only aligned memory accesses are naturally atomic on a given architecture, misaligned objects of the same type have to use locks." – Illiteracy

@MaxLanghof I have to admit, my comment was mainly to express my ignorance and confusion ;). I will have to do a lot more reading to understand what is going on. Hope I will have time to come back to this q/a later... – Archicarp

@user463035818: There are many situations where some particular accesses made to some objects will need to be ordered with respect to each other, but most operations won't. So far as I can tell, however, the Standard has no way of forcing the ordering of operations on "ordinary" objects. – Biparty

@user463035818 In the x86 architecture at the assembly level, atomic objects as such do not exist as far as I know, so at least with respect to x86 I would say that you are right. As you may be aware, what x86 brings are atomic operations via the LOCK prefix. Nothing prevents assembly code from asserting LOCK at an aligned but otherwise arbitrary data address. (At least, that is what the manuals seem to say. Admittedly, I have no actual experience at coding atomics in assembly.) – Eyehole

Answer 2

In my view atomicity - strictly speaking - does not apply to types or objects, it applies to operations, i.e. you can say an operation is atomic or not.

By an "atomic object" we understand an object whose public interface exposes only atomic operations, i.e. all operations you can do with that object are atomic.

In C and C++ it may be that the concepts are defined the other way around: first define atomic objects and then define atomic operations in terms of atomic objects. It probably made sense for C and C++ to define it this way because the wording of the standard is primarily concerned with defining the language. However from a theoretical and abstract functionality perspective atomic operations are the main concern.

The C++ has the standard std::atomic<T> class template which fits the above descriptions.

Avesta

No, both standards explicitly and voluntarily talk about atomic objects. Atomic operations are those that deal with atomic objects. – Chelseachelsey

@JensGustedt well, it probably made sense for C and C++ to define it this way because the wording of the standard is primarily concerned with defining the language. From a theory and abstract functionality perspective atomic operations are the main concern. Reworded the answer. – Avesta

@Avesta Could you please confirm if I understand correctly based on your explanation: when the standard speaks about "an operation A that modifies an atomic object M", does the referred A mean any non-const operations of the std::atomic based object M? E.g. there is the following std::atomic operation: void notify_one() noexcept. It modifies the std::atomic object, but doesn't modify the underlying T object. Does notify_one modify the atomic object M? (Does M refer the std::atomic<T> object, or its underlying T object?) – Pious

Answer 3

I can answer for C, but C++ is indeed intended to be in sync with C on these points.

Yes, when the C standard speaks of "atomic object" it means an object with an effective type that is atomic-qualified. But it also seems that this is not written down explicitly, so it would probably be a good idea to add that. I'll see to that.

Also, other than some people stated, there are no atomic operations in C without atomic objects. This is volontarily fixed like that, such that the atomicity of access to these objects can never be compromized.

Chelseachelsey

If you're going to propose changes to the C standard to clarify this, it would probably be a good idea to clarify the status of sig_atomic_t at the same time, since it has "atomic" in its name but, AFAIK, it is not an _Atomic-qualified type and offers only the weaker guarantee of its being well-defined to store to a volatile sig_atomic_t variable from a signal handler. (I'm not suggesting any substantive change here, only that the text should emphasize that sig_atomic_t is not _Atomic.) – Tailorbird

How should a programmer handle situations where it is necessary to e.g. ensure that an object which has been written via "ordinary" pointers will not have those accesses reordered by the compiler across some particular volatile write that will be performed later in the same thread? – Biparty