Keil Logo

Technical Support

On-Line Manuals

Libraries and Floating Point Support Guide

Preface The ARM C and C++ Libraries Mandatory linkage with the C library C and C++ runtime libraries Summary of the C and C++ runtime libraries Compliance with the Application Binary Interface ( Increasing portability of object files to other CL ARM C and C++ library directory structure Selection of ARM C and C++ library variants based Thumb C libraries C and C++ library features C++ and C libraries and the std namespace Multithreaded support in ARM C libraries ARM C libraries and multithreading ARM C libraries and reentrant functions ARM C libraries and thread-safe functions Use of static data in the C libraries Use of the __user_libspace static data area by the C library functions to access subsections of the _ Re-implementation of legacy function __user_libspa Management of locks in multithreaded applications How to ensure re-implemented mutex functions are c Using the ARM C library in a multithreaded environ Thread safety in the ARM C library Thread safety in the ARM C++ library The floating-point status word in a multithreaded Support for building an application with the C lib Using the C library with an application Using the C and C++ libraries with an application Using $Sub$$ to mix semihosted and nonsemihosted I Using the libraries in a nonsemihosting environmen C++ exceptions in a non-semihosting environment Direct semihosting C library function dependencies Indirect semihosting C library function dependenci C library API definitions for targeting a differen Support for building an application without the C Building an application without the C library Creating an application as bare machine C without Integer and floating-point compiler functions and Bare machine integer C Bare machine C with floating-point processing Customized C library startup code and access to C Using low-level functions when exploiting the C li Using high-level functions when exploiting the C l Using malloc() when exploiting the C library Tailoring the C library to a new execution environ Initialization of the execution environment and ex C++ initialization, construction and destruction Exceptions system initialization Emergency buffer memory for exceptions Library functions called from main() Program exit and the assert macro Assembler macros that tailor locale functions in t Link time selection of the locale subsystem in the Runtime selection of the locale subsystem in the C Definition of locale data blocks in the C library LC_CTYPE data block LC_COLLATE data block LC_MONETARY data block LC_NUMERIC data block LC_TIME data block Modification of C library functions for error sign Stack and heap memory allocation and the ARM C and Library heap usage requirements of the ARM C and C Choosing a heap implementation for memory allocati Stack pointer initialization and heap bounds Legacy support for __user_initial_stackheap() Avoiding the heap and heap-using library functions Tailoring input/output functions in the C and C++ Target dependencies on low-level functions in the The C library printf family of functions The C library scanf family of functions Redefining low-level library functions to enable d The C library functions fread(), fgets() and gets( Re-implementing __backspace() in the C library Re-implementing __backspacewc() in the C library Redefining target-dependent system I/O functions i Tailoring non-input/output C library functions Real-time integer division in the ARM libraries ISO C library implementation definition How the ARM C library fulfills ISO C specification mathlib error handling ISO-compliant implementation of signals supported ISO-compliant C library input/output characteristi Standard C++ library implementation definition C library functions and extensions Compiler generated and library-resident helper fun C and C++ library naming conventions Using macro__ARM_WCHAR_NO_IO to disable FILE decla Using library functions with execute-only memory The ARM C Micro-library Floating-point Support The C and C++ Library Functions reference Floating-point Support Functions Reference

Management of locks in multithreaded applications

1.5.8 Management of locks in multithreaded applications

A thread-safe function protects shared resources from concurrent access using locks. There are functions in the C library that you can re-implement, that enable you to manage the locking mechanisms and so prevent the corruption of shared data such as the heap.

These functions are mutex functions, where the lifecycle of a mutex is one of initialization, iterative acquisition and releasing of the mutex as required, and then optionally freeing the mutex when it is never going to be required again. The mutex functions wrap onto your own Real-Time Operating System (RTOS) calls, and their function prototypes are:
_mutex_initialize()
int _mutex_initialize(mutex *m);
This function accepts a pointer to a 32-bit word and initializes it as a valid mutex.
By default, _mutex_initialize() returns zero for a nonthreaded application. Therefore, in a multithreaded application, _mutex_initialize() must return a nonzero value on success so that at runtime, the library knows that it is being used in a multithreaded environment.
Ensure that _mutex_initialize() initializes the mutex to an unlocked state.
This function must be supplied if you are using mutexes.
_mutex_acquire()
void _mutex_acquire(mutex *m);
This function causes the calling thread to obtain a lock on the supplied mutex.
_mutex_acquire() returns immediately if the mutex has no owner. If the mutex is owned by another thread, _mutex_acquire() must block until it becomes available.
_mutex_acquire() is not called by the thread that already owns the mutex.
This function must be supplied if you are using mutexes.
_mutex_release()
void _mutex_release(mutex *m);
This function causes the calling thread to release the lock on a mutex acquired by _mutex_acquire().
The mutex remains in existence, and can be re-locked by a subsequent call to mutex_acquire().
_mutex_release() assumes that the mutex is owned by the calling thread.
This function must be supplied if you are using mutexes.
_mutex_free()
void _mutex_free(mutex *m);
This function causes the calling thread to free the supplied mutex. Any operating system resources associated with the mutex are freed. The mutex is destroyed and cannot be reused.
_mutex_free() assumes that the mutex is owned by the calling thread.
This function is optional. If you do not supply this function, the C library does not attempt to call it.
The mutex data structure type that is used as the parameter to the _mutex_*() functions is not defined in any of the ARM® Compiler toolchain header files, but must be defined elsewhere. Typically, it is defined as part of RTOS code.
Functions that call _mutex_*() functions create 4 bytes of memory for holding the mutex data structure. __Heap_Initialize() is one such function.
For the C library, a mutex is specified as a single 32-bit word of memory that can be placed anywhere. However, if your mutex implementation requires more space than this, or demands that the mutex be in a special memory area, then you must treat the default mutex as a pointer to a real mutex.
A typical example of a re-implementation framework for _mutex_initialize(), _mutex_acquire(), and _mutex_release() is as follows, where SEMAPHORE_ID, CreateLock(), AcquireLock(), and ReleaseLock() are defined in the RTOS, and (...) implies additional parameters:
int _mutex_initialize(SEMAPHORE_ID *sid)
{
   /* Create a mutex semaphore */
    *sid = CreateLock(...);
    return 1;
}
void _mutex_acquire(SEMAPHORE_ID *sid)
{
    /* Task sleep until get semaphore */
    AcquireLock(*sid, ...);
}
void _mutex_release(SEMAPHORE_ID *sid)
{
    /* Release the semaphore. */
    ReleaseLock(*sid);
}
void _mutex_free(SEMAPHORE_ID *sid)
{
    /* Free the semaphore. */
    FreeLock(*sid, ...);
}

Note

  • _mutex_release() releases the lock on the mutex that was acquired by _mutex_acquire(), but the mutex still exists, and can be re-locked by a subsequent call to _mutex_acquire().
  • It is only when the optional wrapper function _mutex_free() is called that the mutex is destroyed. After the mutex is destroyed, it cannot be used without first calling _mutex_initialize() to set it up again.
Non-ConfidentialPDF file icon PDF versionARM DUI0378H
Copyright © 2007, 2008, 2011, 2012, 2014-2016 ARM. All rights reserved. 
  Arm logo
Important information

This site uses cookies to store information on your computer. By continuing to use our site, you consent to our cookies.

Change Settings

Privacy Policy Update

Arm’s Privacy Policy has been updated. By continuing to use our site, you consent to Arm’s Privacy Policy. Please review our Privacy Policy to learn more about our collection, use and transfers
of your data.