# [C++] Are these operations atomic?

This topic is 3925 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

class Foo
{
...
Foo(Foo& f); // Copy Constructor
...
}

void OperateOnFoo(Foo f);

...

int main()
{
Foo f1;

OperateOnFoo(f); // Argument passing w/ copy construction

Foo f2 = f1; // Copy construction
}


I was wondering: - In C++, is copy construction atomic? - In C++, is argument passing atomic?

##### Share on other sites
C++ has no notion of concurrency, so it places no guarantee on the atomicity of operations. Generally speaking, the answer is "no". Read your compiler's documentation for a less general answer.

##### Share on other sites
No.

From an ACID point of view, the constructor may throw an exception, which thus voids the atomicity. You can make a copy constructor atomic in the ACID sense by ensuring that it does not throw.

From a threading point of view, nothing in C++ is atomic. Some libraries will guarantee some operations to be atomic (but these are typically threading libraries which strive to provide atomic primitives).

##### Share on other sites
Atomicity is very tricky.

As said, nothing in C++, or even in OS is atomic, unless it says so with big bold letters.

It's not something you get accidentally, or through some design. Sun's Java JVM makes explicit guarantees about assignments, and the Java standard mentions the topic, but even then there's need for volatile.

Part of the problem comes from scaling to multi-core processors. There, atomicity becomes a whole different beast than on single-processor.

When developing under Windows, you have a very nice set of Interlocked_XXX operations which are atomic, as guaranteed by OS and hardware. For everything else you'll need to dig deep into bowels of MS's libraries, and the other details that go with atomicity (barriers), as well as implementation details associated with it.

The atomic operations which are guaranteed by hardware are, different, to say the least. Anything large (copy constructor) are a big no-no, and the only way to perform the atomically is to synhronize them. These operations are just so insanely expensive that they cannot be atomic. Doing just a handful of those in a loop would kill any OS scheduler.

• 34
• 12
• 10
• 9
• 9
• ### Forum Statistics

• Total Topics
631354
• Total Posts
2999498
×