Sign in to follow this  

[C++] Are these operations atomic?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Please consider the following example:
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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.

Share this post


Link to post
Share on other sites

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

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this