Does std::atomic<std::string> work appropriately?

Question

I am reading through Anthony Williams' "C++ Concurrency in Action" and in Chapter 5, which talks about the new multithreading-aware memory model and atomic operations, and he states:

In order to use std::atomic<UDT> for some user-defined UDT, this type must have a trivial copy assignment operator.

As I understand it, this means that we can use std::atomic<UDT> if the following returns true:

std::is_trivially_copyable<UDT>::value

By this logic, we shouldn't be able to use std::string as a template argument for std::atomic and have it work correctly.

However, the following code compiles and runs with expected output:

#include <atomic>
#include <thread>
#include <iostream>
#include <string>

int main()
{
    std::atomic<std::string> atomicString;

    atomicString.store( "TestString1" );

    std::cout << atomicString.load() << std::endl;

    atomicString.store( "TestString2" );

    std::cout << atomicString.load() << std::endl;

    return 0;
}

Is this a case of undefined behaviour which just happens to behave as expected?

Thanks in advance!

Answer 1

The standard does not specify a specialization of std::atomic<std::string>, so the generic template <typename T> std::atomic<T> applies. 29.5 [atomics.types.generic] p1 states:

There is a generic class template atomic. The type of the template argument T shall be trivially copyable (3.9).

There is no statement that the implementation must diagnose violations of this requirement. So either (a) your use of std::atomic<std::string> invokes undefined behavior, or (b) your implementation provides std::atomic<std::string> as a conforming extension.

Looking at the MSDN page for std::atomic<T> (http://msdn.microsoft.com/en-us/library/vstudio/hh874651.aspx), it does explicitly mention the requirement that T be trivially copyable, and it does NOT say anything specific about std::atomic<std::string>. If it is an extension, it's undocumented. My money is on undefined behavior.

Specifically, 17.6.4.8/1 applies (with thanks to Daniel Krügler for setting me straight):

In certain cases (replacement functions, handler functions, operations on types used to instantiate standard library template components), the C++ standard library depends on components supplied by a C++ program. If these components do not meet their requirements, the Standard places no requirements on the implementation.

std::string certainly does not meet the std::atomic<T> requirement that the template parameter T be trivially copyable, so the standard places no requirements on the implementation. As a quality of implementation issue, note that static_assert(std::is_trivially_copyable<T>::value, "std::atomic<T> requires T to be trivially copyable"); is an easy diagnostic to catch this violation.

---

2016-04-19 Update: I don't know when the change happened, but VS2015 Update 2 does now diagnose std::atomic<std::string>:

error C2338: atomic requires T to be trivially copyable.

Answer 2

No, this is undefined behavior. Moreover, since std::string is not trivially copyable, conforming compiler should have issued "at least one diagnostic message":

29.5 Atomic types

There is a generic class template atomic. The type of the template argument T shall be trivially copyable (3.9).

1.4 Implementation compliance

— If a program contains a violation of any diagnosable rule [...] a conforming implementation shall issue at least one diagnostic message.

Answer 3

Why do you think this will work 'correctly' when there are multiple threads trying to read/write the std::atomic<std::string>?

This is C++, you are definitely allowed to shoot yourself in the foot. If you want to use a type which does not satisfy the requirements you are free to use, the compiler "may" (not will!) stop you, but you will start seeing weird/unexplainable behaviour at some point when multiple threads try to read/write the string.

This requirement is for guaranteeing atomicity of reads and writes, if the object is not trivially copyable then visualize this scene: The string had "Old Value" in it. 1 Writer issues .store("New Data"), now there is another thread which issues .load() on the same variable, now without a trivially_copyable property, the reader thread can see "Nld Value" or "New Value" etc. It can't be updated atomically, hence the weird results.

Since the example you posted is a sequential code, this does not happen.