As of V2.92.08, μCµC/OS-II provides built-in support for run-time library thread safety through the use of Task Local Storage (TLS) for storage of task-specific run-time library static data and mutual exclusion semaphores to protect accesses to shared resources.
...
When OS_TLS_TBL_SIZE is set to 1 or greater, each task’s OS_TCB will contain a new array called .OSTCBTLSTbl[] as shown below. Each array element is of type OS_TLS which is actually a pointer to void. This allows an OS_TCB to be extended so that it can have as many TLS areas as needed.
The number of entries (i.e., the value to set OS_TLS_TBL_SIZE to) depends on the compiler being supported as well as whether TLS storage is needed for other purposes.
OS_TLS_GetID()
The index into .OSTCBTLSTbl[] is called the TLS ID and TLS IDs are assigned through an API function. In other words, TLS IDs are assigned dynamically as needed. Once a TLS ID is assigned for a specific purpose, it cannot be ‘unassigned’. The function used to assign a TLS ID is called OS_TLS_GetID().
...
This function is called by OSInit() and in fact, is called after creating the kernel objects but before creating any of the internal μCµC/OS-III tasks. This means that OS_TLS_Init() is allowed to create event flags, semaphores, mutexes and message queues. OS_TLS_Init() would typically create mutexes to protect access to shared resources such as the heap or streams.
...
As previously mentioned, some compilers may already have declared API functions that are called to ensure exclusive access to shared resources. For example, APIs such as _mutex_lock_file_system() and _mutex_unlock_file_system() could be required by the compiler to ensure exclusive access to the file system. os_tls.c might then implement these using μCµC/OS-III as shown below. Note that we also included the code to initialize the mutex in OS_TLS_Init().
The compiler may require the implementation of many such API functions to ensure exclusive access to the heap, environment variables, etc. These would all be found in os_tls.c.