The heap functions are thread-safe.

A single heap is shared between all threads, and mutexes are used to avoid data corruption when there is concurrent access. Each heap implementation is responsible for doing its own locking. If you supply your own allocator, it must also do its own locking. This enables it to do fine-grained locking, if required, rather than simply protecting the entire heap with a single mutex (coarse-grained locking).

__alloca(), __alloca_finish(), __alloca_init(), __alloca_initialize()

The alloca functions are thread-safe.

The alloca state for each thread is contained in the __user_perthread_libspace block. This means that multiple threads do not conflict.

The ARM signal handling functions and FP exception traps are thread-safe.

The settings for signal handlers and FP traps are global across the entire process and are protected by locks. Data corruption does not occur if multiple threads call signal() or an fenv.h function at the same time. However, be aware that the effects of the call act on all threads and not just on the calling thread.

clearerr(), fclose(), feof(), ferror(), fflush(), fgetc(), fgetpos(), fgets(), fopen(), fputc(), fputs(), fread(), freopen(), fseek(), fsetpos(), ftell(), fwrite(), getc(), getchar(), gets(), perror(), putc(), putchar(), puts(), rewind(), setbuf(), setvbuf(), tmpfile(), tmpnam(), ungetc()

The stdio library is thread-safe.

Each individual stream is protected by a lock, so two threads can each open their own stdio stream and use it, without interfering with one another.

If two threads both want to read or write the same stream, locking at the fgetc() and fputc() level prevents data corruption, but it is possible that the individual characters output by each thread might be interleaved in a confusing way.

fprintf(), printf(), vfprintf(), vprintf(), fscanf(), scanf()

When using these functions:

clock()

errno()

errno is thread-safe.

Each thread has its own errno stored in a __user_perthread_libspace block. This means that each thread can call errno-setting functions independently and then check errno afterwards without fearing other threads.

The list of exit functions maintained by atexit() is process-global and protected by a lock.

In the worst case, if more than one thread calls atexit(), the order that exit functions are called cannot be guaranteed.

abs(), acos(), asin(), atan(), atan2(), atof(), atol(), atoi(), bsearch(), ceil(), cos(), cosh(), difftime(), div(), exp(), fabs(), floor(), fmod(), frexp(), labs(), ldexp(), ldiv(), log(), log10(), memchr(), memcmp(), memcpy(), memmove(), memset(), mktime(), modf(), pow(), qsort(), sin(), sinh(), sqrt(), strcat(), strchr(), strcmp(), strcpy(), strcspn(), strlen(), strncat(), strncmp(), strncpy(), strpbrk(), strrchr(), strspn(), strstr(), strxfrm(), tan(), tanh()

These functions are thread-safe.

longjmp(), setjmp()

Although setjmp() and longjmp() keep data in __user_libspace, they call the __alloca_* functions, which are thread-safe.

remove(), rename(), time()

These use SWIs that communicate with the ARM debugging environments. Typically, you have to re-implement these for a real-world application.

snprintf(), sprintf(), vsnprintf(), vsprintf(), sscanf(), isalnum(), isalpha(), iscntrl(), isdigit(), isgraph(), islower(), isprint(), ispunct(), isspace(), isupper(), isxdigit(), tolower(), toupper(), strcoll(), strtod(), strtol(), strtoul(), strftime()

When using these functions, the string-based functions read the locale settings. Typically, they are thread-safe. However, if you change locale in mid-session, you should ensure that these functions are not affected.

The string-based functions, such as sprintf() and sscanf(), do not depend on the stdio library.

setlocale()

The locale settings are global across all threads, and are not protected by a lock. If two threads call setlocale(), there might be data corruption. Also, many other functions, for example strtod() and sprintf(), read the current locale settings. So, if one thread calls setlocale() concurrently with another thread calling such a function then there might be unexpected results.

ARM recommends that you choose the locale you want and call setlocale() once to initialize it. Do this before creating any additional threads in your program so that any number of threads can read the locale settings concurrently without interfering with one another.

Be aware that localeconv() is not thread-safe. Call the ARM function _get_lconv() with a pointer to a user-supplied buffer instead.

asctime(), localtime(), strtok()

These functions are all thread-unsafe. Each contains a static buffer that might be overwritten by another thread between a call to the function and the subsequent use of its return value.

ARM supplies reentrant versions, asctime_r(), localtime_r(), and strtok_r(), as specified by POSIX. ARM recommends that you use these functions instead to ensure safety.

mbrlen(), mbsrtowcs(), mbrtowc(), wcrtomb(), wcsrtombs()

The C89 multibyte conversion functions (defined in stdlib.h) are not thread-safe, for example mblen() and mbtowc(), because they contain internal static state that is shared between all threads without locking.

However, the extended restartable versions (defined in wchar.h) are thread-safe, for example mbrtowc() and wcrtomb(), provided you pass in a pointer to your own mbstate_t object. You must exclusively use these functions with non-NULL mbstate_t * parameters if you want to ensure thread-safety when handling multibyte strings.

Do not call exit(), in a multithreaded program, even if you have provided an implementation of the underlying _sys_exit() that actually terminates all threads.

In this case, exit() cleans up before calling _sys_exit() and so disrupts other threads.

These functions keep internal state that is both global and unprotected. This means that calls to rand() are never thread-safe

ARM recommends that you use your own locking to ensure that only one thread ever calls rand() at a time, for example, by defining $Sub$$rand() if you want to avoid changing your code.

Alternatively, do one of the following: