By thb


2019-02-26 12:27:49 8 Comments

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.

3 comments

@bolov 2019-02-26 12:38:16

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.

@Jens Gustedt 2019-02-26 13:08:18

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

@bolov 2019-02-26 13:28:46

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

@eerorika 2019-02-26 12:41:35

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.

@user463035818 2019-02-26 12:50:14

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"

@eerorika 2019-02-26 12:53:25

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

@Max Langhof 2019-02-26 13:15:53

@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."

@user463035818 2019-02-26 13:17:25

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

@supercat 2019-02-26 22:05:12

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

@thb 2019-02-27 14:24:24

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

@Jens Gustedt 2019-02-26 13:19:14

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.

@zwol 2019-02-26 16:18:24

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

@supercat 2019-02-26 22:11:48

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?

Related Questions

Sponsored Content

14 Answered Questions

[SOLVED] Purpose of Unions in C and C++

6 Answered Questions

[SOLVED] What's the meaning of "reserved for any use"?

27 Answered Questions

[SOLVED] What's the difference between the atomic and nonatomic attributes?

0 Answered Questions

Is the standard's ODR example correct?

1 Answered Questions

[SOLVED] The Definitive C++ Book Guide and List

  • 2008-12-23 05:23:56
  • grepsedawk
  • 2087715 View
  • 4250 Score
  • 1 Answer
  • Tags:   c++ c++-faq

22 Answered Questions

12 Answered Questions

[SOLVED] typedef struct vs struct definitions

  • 2009-11-04 17:21:57
  • user69514
  • 586691 View
  • 695 Score
  • 12 Answer
  • Tags:   c struct typedef

1 Answered Questions

[SOLVED] Is a relaxed atomic counter safe?

21 Answered Questions

[SOLVED] Why should I use a pointer rather than the object itself?

  • 2014-03-03 11:54:16
  • gEdringer
  • 276395 View
  • 1432 Score
  • 21 Answer
  • Tags:   c++ pointers c++11

11 Answered Questions

[SOLVED] Why is f(i = -1, i = -1) undefined behavior?

Sponsored Content