Return to Answer

is there any issue running on other architecture (weak memory order)?

Well, std::atomic isn't guaranteed by the standard to be lock free. It totally depends on the target CPU's architecture, and capabilities.

If there are single operations supported by the CPU to access and change specific values, they will be lock free. Otherwise any operations on std::atomic may need to use an implementation that involve a synchronization mechanism (semaphore or mutex).

For reference you can read

• std::atomic_is_lock_free, ATOMIC_xxx_LOCK_FREE how to determine that at compile time

and

• Are atomic variables lock-free?

is there any issue running on other architecture (weak memory order)?

Well, std::atomic isn't guaranteed by the standard to be lock free. It totally depends on the target CPU's architecture, and capabilities.

If there are single operations supported by the CPU to access and change specific values, they will be lock free. Otherwise any operations on std::atomic may need to use an implementation that involve a synchronization mechanism (semaphore or mutex).

For reference you can read

• std::atomic_is_lock_free, ATOMIC_xxx_LOCK_FREE how to determine that at compile time

and

• Are atomic variables lock-free?

is there any issue running on other architecture (weak memory order)?

Well, std::atomic isn't guaranteed by the standard to be lock free. It totally depends on the target CPU's architecture, and capabilities.

If there are single operations supported by the CPU to access and change specific values, they will be lock free. Otherwise any operations on std::atomic may need to use an implementation that involve a synchronization mechanism (semapore or mutex).

For reference you can read

• std::atomic_is_lock_free, ATOMIC_xxx_LOCK_FREE how to determine that at compile time

and

• Are atomic variables lock-free?

is there any issue running on other architecture (weak memory order)?

Well, std::atomic isn't guaranteed by the standard to be lock free. It totally depends on the target CPU's architecture, and capabilities.

If there are single operations supported by the CPU to access and change specific values, they will be lock free. Otherwise any operations on std::atomic may need to use an implementation that involve a synchronization mechanism (semaphore or mutex).

For reference you can read

• std::atomic_is_lock_free, ATOMIC_xxx_LOCK_FREE how to determine that at compile time

and

• Are atomic variables lock-free?

is there any issue running on other architecture (weak memory order)?

Well, std::atomic isn't guaranteed by the standard to be lock free. It totally depends on the target CPU's architecture.

For reference you can read

• std::atomic_is_lock_free, ATOMIC_xxx_LOCK_FREE how to determine that at compile time

and

• Are atomic variables lock-free?

is there any issue running on other architecture (weak memory order)?

Well, std::atomic isn't guaranteed by the standard to be lock free. It totally depends on the target CPU's architecture, and capabilities.

If there are single operations supported by the CPU to access and change specific values, they will be lock free. Otherwise any operations on std::atomic may need to use an implementation that involve a synchronization mechanism (semapore or mutex).

For reference you can read

• std::atomic_is_lock_free, ATOMIC_xxx_LOCK_FREE how to determine that at compile time

and

• Are atomic variables lock-free?