Boost.Atomic provides a unit test suite
to verify that the implementation behaves as expected:
-
atomic_api.cpp and atomic_ref_api.cpp
verifies that all atomic operations have correct value semantics (e.g.
"fetch_add" really adds the desired value, returning the previous).
The latter tests
atomic_ref
rather than atomic
and
atomic_flag
. It is a
rough "smoke-test" to help weed out the most obvious mistakes
(for example width overflow, signed/unsigned extension, ...). These tests
are also run with BOOST_ATOMIC_FORCE_FALLBACK
macro defined to test the lock pool based implementation.
-
lockfree.cpp verifies that the BOOST_ATOMIC_*_LOCKFREE macros are set properly
according to the expectations for a given platform, and that they match
up with the is_always_lock_free and
is_lock_free members of the atomic object instances.
-
atomicity.cpp and atomicity_ref.cpp
lets two threads race against each other modifying a shared variable,
verifying that the operations behave atomic as appropriate. By nature,
this test is necessarily stochastic, and the test self-calibrates to
yield 99% confidence that a positive result indicates absence of an error.
This test is very useful on uni-processor systems with preemption already.
-
ordering.cpp and ordering_ref.cpp
lets two threads race against each other accessing multiple shared variables,
verifying that the operations exhibit the expected ordering behavior.
By nature, this test is necessarily stochastic, and the test attempts
to self-calibrate to yield 99% confidence that a positive result indicates
absence of an error. This only works on true multi-processor (or multi-core)
systems. It does not yield any result on uni-processor systems or emulators
(due to there being no observable reordering even the order=relaxed case)
and will report that fact.
-
wait_api.cpp and wait_ref_api.cpp
are used to verify waiting and notifying operations behavior. Due to
the possibility of spurious wakeups, these tests may fail if a waiting
operation returns early a number of times. The test retries for a few
times in this case, but a failure is still possible.
-
wait_fuzz.cpp is a fuzzing test for
waiting and notifying operations, that creates a number of threads that
block on the same atomic object and then wake up one or all of them a
number of times. This test is intended as a smoke test in case if the
implementation has long-term instabilities or races (primarily, in the
lock pool implementation).
-
ipc_atomic_api.cpp, ipc_atomic_ref_api.cpp,
ipc_wait_api.cpp and ipc_wait_ref_api.cpp
are similar to the tests without the ipc_
prefix, but test IPC atomic types.