1.5.12 Thread safety in the ARM C++ library

ARM C++ library functions are either always thread-safe, never thread-safe, or thread-safe in certain circumstances.

The following points summarize thread safety in the C++ library:

  • The function std::set_new_handler() is not thread-safe. This means that some forms of ::operator new and ::operator delete are not thread-safe with respect to std::set_new_handler():

    • The default C++ runtime library implementations of the following use malloc() and free() and are thread-safe with respect to each other. They are not thread-safe with respect to std::set_new_handler(). You are permitted to replace them:

      ::operator new(std::size_t)

      ::operator new[](std::size_t)

      ::operator new(std::size_t, const std::nothrow_t&)

      ::operator new[](std::size_t, const std::nothrow_t)

      ::operator delete(void*)

      ::operator delete[](void*)

      ::operator delete(void*, const std::nothrow_t&)

      ::operator delete[](void*, const std::nothrow_t&)

    • The following placement forms are also thread-safe. You are not permitted to replace them:

      ::operator new(std::size_t, void*)

      ::operator new[](std::size_t, void*)

      ::operator delete(void*, void*)

      ::operator delete[](void*, void*)

  • Construction and destruction of global objects are not thread-safe.

  • Construction of local static objects can be made thread-safe if you re-implement the functions __cxa_guard_acquire(), __cxa_guard_release(), __cxa_guard_abort(), __cxa_atexit() and __aeabi_atexit() appropriately. For example, with appropriate re-implementation, the following construction of lsobj can be made thread-safe:

    struct T { T(); };
    void f() { static T lsobj; }
  • Throwing an exception is thread-safe if any user constructors and destructors that get called are also thread-safe.

  • The ARM C++ library uses the ARM C library. To use the ARM C++ library in a multithreaded environment, you must provide the same functions that you would be required to provide when using the ARM C library in a multithreaded environment.

Rogue Wave Standard C++ library

The Rogue Wave Standard C++ library is a part of the ARM C++ library. What applies to the ARM C++ library applies to the Rogue Wave Standard C++ library too. In the Rogue Wave Standard C++ library, specifically:

  • All containers and all functions are reentrant, making no use of internal, modifiable static data.

    • Except for the std::random_shuffle function, which uses static data to record the state of the random number generator.

  • The iostream and locale classes are not thread safe.

You must protect shared objects while using the iostream and locale classes, and the std::random_shuffle function. To do this, you might use mutex functions, or co-operative threading. As an example, in a typical case of a pre-emptive multitasking environment, one that uses mutex functions with containers, this means that:

  • Reader threads can safely share a container if no thread writes to it during the reads.

  • While a thread writes to a shared container, you must apply locking around the use of the container.

  • Writer threads can write to different containers safely.

  • You must apply locking around the use of random_shuffle.

  • Multiple threads cannot use iostream and locale classes safely unless you apply locking around the use of their objects.

Non-ConfidentialPDF file icon PDF versionARM DUI0475M
Copyright © 2010-2016 ARM Limited or its affiliates. All rights reserved.