An implementation of __user_perthread_libspace() that returns a different block of memory for each thread. This can be achieved by either:

You can use either approach to suit your environment.

You do not have to re-implement __user_perproc_libspace unless there is a specific reason to do so. In the majority of cases, there is no requirement to re-implement this function.

Implementations of the three mutex functions (see Managing locks in multithreaded applications).

In some applications these functions might not do anything useful. For example, a co-operatively threaded program does not have to take any steps to ensure data integrity, provided it avoids calling its yield function during a critical section. However, in other types of application, for example where you are implementing pre-emptive threading or in a Symmetric Multi-Processor (SMP) model, these functions play an important part in handling locks.

A way to manage multiple stacks.

A simple way to do this is to use the ARM two-region memory model (see The memory models). Using this means that you keep the stack that belongs to the primary thread entirely separate from the heap. Then you must allocate further memory for additional stacks from the heap itself.

Thread management functions, for example, to create or destroy threads, to handle thread synchronization, and to retrieve exit codes.

A thread-switching mechanism.

some functions work independently in each thread

some functions automatically use the mutex functions to mediate multiple accesses to a shared resource

some functions are still non-reentrant and so a reentrant equivalent is supplied

a few functions remain non-reentrant and no alternative is available.