并发读取非原子变量

Question

I encounter this question while trying to implement a shared pointer. Let's focus on the managed data pointer. Its lifetime can be divided into three stages:

1. Construction where there is no concurrent access.
2. Concurrent reads on it (no writes).
3. Destruction where there is no concurrent access. This is guaranteed by reference counting.

My question is, given this situation, is it necessary for the pointer to be atomic? I think it's equivalent to: will stage 2 lead to undefined behavior if the pointer is not atomic? Ideally, I want to hear an answer discussing from both a theoretical (language-lawyer) point of view and a practical point of view. For example, if not atomic, stage 2 may be undefined behavior theoretically, but is practically OK on actual platforms. For implementing shared pointer, if non-atomic is OK, the managed pointer can be unique_ptr<T> , otherwise it has to be atomic<T*> .

Update

I find the standard text (Section 1.10 p21):

The execution of a program contains a data race if it contains two conflicting actions in different threads, at least one of which is not atomic, and neither happens before the other. Any such data race results in undefined behavior.

I guess concurrent reads do not classify as conflicting actions. Could somebody find some standard text about this to be sure?

Answer 1

The rule is that if more than one thread accesses the same object at the same time and at least one of those threads is modifying the data, then you have a data race, and the behavior of the program is undefined. If nobody is modifying the object there is no problem from the concurrent accesses.

Answer 2

Find the answer myself. Quoted from first paragraph, Section 5.1.2 in C++ Concurrency in Action :

[...] If neither thread is updating the memory location, you're fine; read-only data doesn't need protection or synchronization. If either thread is modifying the data, there's a potential for a race condition, as described in chapter 3.

Answer 3

Concurrent reads on any variable, whether atomic or not, do not constitute a data race, because of the definition of conflicting evaluations, found in [intro.multithread] :

Two expression evaluations conflict if one of them modifies a memory location and the other one accesses or modifies the same memory location.

Recently, this has moved to [intro.races] with a very subtle change in wording

Two expression evaluations conflict if one of them modifies a memory location and the other one reads or modifies the same memory location.

The change from accesses to reads took place between draft n4296 and n4431. The splitting of the multithreading section took place between n4582 and n4604.

Answer 4

So I suppose you are talking of the structure holding the counter and a pointer to the owned data:

template<class ValueType>
struct shared_counter{
  std::atomic<int> count=0;
  const std::unique_ptr<ValueType> ptr;
  //Your question is: Does ptr should be atomic?
  //... This is a dumb implementation, only focusing on the subject.
  };

In practice, ptr does not need to be atomic because if reference counting is implemented appropriatly, all access to ptr will be sequenced before the desctruction of shared_counter.

To ensure that, inside the destructor of a shared_ptr the counter is decremented through a read-modify-write with acquire-release memory order:

template<class ValueType>
struct shared_ptr{
   shared_counter<ValueType>* counted_ptr;
   //...
   void reset(){
     if (counted_ptr->count.fetch_sub(1,std::memory_order_acq_rel) == 1)
       counter_ptr->~shared_counter<ValueType>();
     counter_ptr=nullptr;
     }
   };

Thanks to this memory order, if the fetched value of count is 1 in thread A, this means that in all other threads where other shared_ptrs pointing to the same shared_counter will not access any more this shared_counter . The memory order ensure that accesses performed to this shared_counter in these other threads will happen before the fetch of the value 1 in thread A. (release in other thread -> acquire in the thread that will call the destructor).

So there is no need to have ptr to be atomic because the counter decrementation cause sufficient sequencing.