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_refrather thanatomicandatomic_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 withBOOST_ATOMIC_FORCE_FALLBACKmacro 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.