Libraries and Floating Point Support Guide

Thread safety in the ARM C++ library

ARM Compiler toolchain v5.02 for µVision Using ARM C and C++ Libraries and Floating-Point Support

Home > The ARM C and C++ libraries > Thread safety in the ARM C++ library

Thread safety in the ARM C++ library

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 random number
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.

Libraries and Floating Point Support Guide

Thread safety in the ARM C++ library

Thread safety in the ARM C++ library

Rogue Wave Standard C++ library

See also

Products

Development Tools

Hardware & Collateral

Downloads

Support

Contact

Important information