RT-Thread RTOS
An open source embedded real-time operating system
|
POSIX Threads is abbreviated as Pthreads. POSIX is the abbreviation of "Portable Operating System Interface". POSIX is a set of standards established by IEEE Computer Society to improve the compatibility of different operating systems and the portability of applications. Pthreads is a threaded POSIX standard defined in the POSIX.1c, Threads extensions (IEEE Std1003.1c-1995) standard, which defines a set of C programming language types, functions, and constants. Defined in the pthread.h
header file and a thread library, there are about 100 APIs, all of which have a "`pthread_`" prefix and can be divided into 4 categories:
POSIX semaphores are used with Pthreads, but are not part of the Pthreads standard definition and are defined in POSIX.1b, Real-time extensions (IEEE Std1003.1b-1993). Therefore the prefix of the semaphore correlation function is "`sem_`" instead of "`pthread_`".
Message queues, like semaphores, are used with Pthreads and are not part of the Pthreads standard definition and are defined in the IEEE Std 1003.1-2001 standard. The prefix of the message queue related function is "`mq_`".
Function Prefix | Function Group |
---|---|
pthread_ | Thread itself and various related functions |
pthread_attr_ | Thread attribute object |
Pthread_mutex_ | Mutex |
pthread_mutexattr_ | Mutex attribute object |
pthread_cond_ | Conditional variable |
pthread_condattr_ | Condition variable attribute object |
pthread_rwlock_ | Read-write lock |
pthread_rwlockattr_ | Read-write lock attribute object |
pthread_spin_ | Spin lock |
pthread_barrier_ | Barrier |
pthread_barrierattr_ | Barrier attribute object |
sem_ | Semaphore |
mq_ | Message queue |
Most Pthreads functions return a value of 0 if they succeed, and an error code contained in the errno.h
header file if unsuccessful. Many operating systems support Pthreads, such as Linux, MacOSX, Android, and Solaris, so applications written using Pthreads functions are very portable and can be compiled and run directly on many platforms that support Pthreads.
Using the POSIX API interface in RT-Thread includes several parts: libc (for example, newlib), filesystem, pthread, and so on. Need to open the relevant options in rtconfig.h:
RT-Thread implements most of the functions and constants of Pthreads, defined in the pthread.h, mqueue.h, semaphore.h, and sched.h header files according to the POSIX standard. Pthreads is a sublibrary of libc, and Pthreads in RT-Thread are based on the encapsulation of RT-Thread kernel functions, making them POSIX compliant. The Pthreads functions and related functions implemented in RT-Thread are described in detail in the following sections.
Pthread_t
is a redefinition of the rt_thread_t
type, defined in the pthread.h
header file. rt_thread_t is the thread handle (or thread identifier) of the RT-Thread and is a pointer to the thread control block. You need to define a variable of type pthread_t before creating a thread. Each thread corresponds to its own thread control block, which is a data structure used by the operating system to control threads. It stores some information about the thread, such as priority, thread name, and thread stack address. Thread control blocks and thread specific information are described in detail in the Thread Management chapter.
Parameter | Description |
---|---|
tid | Pointer to thread handle (thread identifier), cannot be NULL |
attr | Pointer to the thread property, if NULL is used, the default thread property is used |
start | Thread entry function address |
arg | The argument passed to the thread entry function |
return | —— |
0 | succeeded |
EINVAL | Invalid parameter |
ENOMEM | Dynamic allocation of memory failed |
This function creates a pthread thread. This function dynamically allocates the POSIX thread data block and the RT-Thread thread control block, and saves the start address (thread ID) of the thread control block in the memory pointed to by the parameter tid, which can be used to operate in other threads. This thread; and the thread attribute pointed to by attr, the thread entry function pointed to by start, and the entry function parameter arg are stored in the thread data block and the thread control block. If the thread is created successfully, the thread immediately enters the ready state and participates in the scheduling of the system. If the thread creation fails, the resources occupied by the thread are released.
Thread properties and related functions are described in detail in the Thread Advanced Programming chapter. In general, the default properties can be used.
After the pthread thread is created, if the thread needs to be created repeatedly, you need to set the pthread thread to detach mode, or use pthread_join to wait for the created pthread thread to finish.
The following program initializes two threads, which have a common entry function, but their entry parameters are not the same. Others, they have the same priority and are scheduled for rotation in time slices.
Parameter | Description |
---|---|
thread | Thread handle (thread identifier) |
return | —— |
0 | succeeded |
Call this function, If the pthread does not finish running, set the detach state of the thread thread property to detached; when the thread thread has finished, the system will reclaim the resources occupied by the pthread thread.
Usage: The child thread calls pthread_detach(pthread_self())
(pthread_self() returns the thread handle of the currently calling thread), or another thread calls pthread_detach(thread_id)
. The separation state of the thread attributes will be described in detail later.
Once the detach state of the thread property is set to detached, the thread cannot be waited by the pthread_join() function or re-set to detached.
The following program initializes 2 threads, which have the same priority and are scheduled according to the time slice. Both threads will be set to the detached state. The 2 threads will automatically exit after printing 3 times of information. After exiting, the system will automatically reclaim its resources.
Parameter | Description |
---|---|
thread | Thread handle (thread identifier) |
value_ptr | User-defined pointer to store the return value of the waiting thread, which can be obtained by the function pthread_join() |
Return | —— |
0 | succeeded |
EDEADLK | Thread join itself |
EINVAL | Join a thread with a detached state |
ESRCH | Could not find the thread |
The thread calling this function blocks and waits for the thread with the joinable property to finish running and gets the return value of the thread. The address of the returned value is stored in value_ptr
and frees the resources held by thread.
The pthread_join() and pthread_detach() functions are similar in that they are used to reclaim the resources occupied by threads after the thread running ends. A thread cannot wait for itself to end. The detached state of the thread thread must be joinable
, and one thread only corresponds to the pthread_join()
call. A thread with a split state of joinable will only release the resources it occupies when other threads execute pthread_join()
on it. So in order to avoid memory leaks, all threads that will end up running, either detached or set to detached, or use pthread_join() to reclaim the resources they consume.
The following program code initializes 2 threads, they have the same priority, and the threads of the same priority are scheduled according to the time slice. The separation status of the 2 thread attributes is the default value joinable, and thread 1 starts running first, and ends after printing 3 times of information. Thread 2 calls pthread_join() to block waiting for thread 1 to end, and reclaims the resources occupied by thread 1, and thread 2 prints the message every 2 seconds.
Parameter | Description |
---|---|
value_ptr | User-defined pointer to store the return value of the waiting thread, which can be obtained by the function pthread_join() |
Calling this function by the pthread thread terminates execution, just as the process calls the exit() function and returns a pointer to the value returned by the thread. The thread exit is initiated by the thread itself.
If the split state of the thread is joinable, the resources occupied by the thread will not be released after the thread exits. The pthread_join() function must be called to release the resources occupied by the thread.
This program initializes 2 threads, they have the same priority, and the threads of the same priority are scheduled according to the time slice. The separation state of the two thread attributes is the default value joinable, and thread 1 starts running first, sleeps for 2 seconds after printing the information once, and then prints the exit information and then ends the operation. Thread 2 calls pthread_join() to block waiting for thread 1 to end, and reclaims the resources occupied by thread 1, and thread 2 prints the message every 2 seconds.
Mutexes, also known as mutually exclusive semaphores, are a special binary semaphore. Mutexes are used to ensure the integrity of shared resources. Only one thread can access the shared resource at any time. To access shared resources, the thread must first obtain the mutex. After the access is complete, the mutex must be released. Embedded shared resources include memory, IO, SCI, SPI, etc. If two threads access shared resources at the same time, there may be problems because one thread may use the resource while another thread modifies the shared resource and consider sharing.
There are only two kinds of operations of mutex, locking or unlocking, and only one thread holds a mutex at a time. When a thread holds it, the mutex is latched and its ownership is obtained by this thread. Conversely, when this thread releases it, it unlocks the mutex and loses its ownership. When a thread holds a mutex, other threads will not be able to unlock it or hold it.
The main APIs of the mutex include: calling pthread_mutex_init()
to initialize a mutex, pthread_mutex_destroy()
to destroy the mutex, pthread_mutex_lock() to lock the mutex, and pthread_mutex_unlock()
to unlock the mutex.
The rt-thread operating system implements a priority inheritance algorithm to prevent priority inversion.Priority inheritance is the practice of raising the priority of a low-priority thread that occupies a resource to the same level as the highest-priority thread of all the threads waiting for the resource, then executing, and then returning to the initial setting when the low-priority thread releases the resource.Thus, threads that inherit priority prevent system resources from being preempted by any intermediate priority thread.
For a detailed introduction to priority reversal, please refer to the Inter-thread Synchronization Mutex section.
Each mutex corresponds to a mutex control block that contains some information about the control of the mutex. Before creating a mutex, you must first define a variable of type pthread_mutex_t
. pthread_mutex_t is a redefinition of pthread_mutex. The pthread_mutex data structure is defined in the pthread.h header file. The data structure is as follows:
Parameter | Description |
---|---|
mutex | Mutex lock handle, cannot be NULL |
attr | Pointer to the mutex attribute, if the pointer is NULL, the default attribute is used. |
return | —— |
0 | succeeded |
EINVAL | Invalid parameter |
This function initializes the mutex mutex
and sets the mutex property according to the mutex attribute object pointed to by attr
. After successful initialization, the mutex is unlocked and the thread can obtain it. This function encapsulates the rt_mutex_init() function.
In addition to calling the pthread_mutex_init() function to create a mutex, you can also statically initialize the mutex with the macro PTHREAD_MUTEX_INITIALIZER by: pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER
(structure constant), which is equivalent to specifying attr to NULL when calling pthread_mutex_init().
The mutex lock properties and related functions are described in detail in the thread advanced programming chapter. In general, the default properties can be used.
Parameter | Description |
---|---|
mutex | Mutex lock handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Mutex is empty or mutex has been destroyed |
EBUSY | Mutex is being used |
This function destroys the mutex mutex
. Mutex is mutable in an uninitialized state after destruction. After destroying the mutex's properties and control block parameters will not be valid, but you can call pthread_mutex_init() to reinitialize the destroyed mutex. However, there is no need to destroy the mutex that is statically initialized with the macro PTHREAD_MUTEX_INITIALIZER.
The mutex can be destroyed when it is determined that the mutex is not locked and no thread is blocked on the mutex.
Parameter | Description |
---|---|
mutex | Mutex lock handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EDEADLK | Mutexes mutex do not call this function repeatedly for a thread with a nested lock |
This function locks the mutex mutex
, which is a wrapper of the rt_mutex_take() function. If the mutex has not been locked yet, the thread applying for the mutex will successfully lock the mutex. If the mutex has been locked by the current thread and the mutex type is a nested lock, the mutex's holding count is incremented by one, and the current thread will not suspend waiting (deadlock), but the thread must corresponds to the same number of unlocks. If the mutex is held by another thread, the current thread will be blocked until the other thread unlocks the mutex, and the thread waiting for the mutex will acquire the mutex according to the first in first out principle. .
Parameter | Description |
---|---|
mutex | Mutex lock handle, cannot be NULL |
return | —— |
0 | succeeded |
EINVAL | Invalid parameter |
EDEADLK | Mutexes are not nested locks, but threads call this function repeatedly |
EBUSY | Mutexes mutex has been locked by other threads |
This function is a non-blocking version of the pthread_mutex_lock() function. The difference is that if the mutex has been locked, the thread will not be blocked, but the error code will be returned immediately.
Parameter | Description |
---|---|
mutex | Mutex lock handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EPERM | This function is called repeatedly by a thread when the mutex is not a nested lock |
EBUSY | Unlock the mutex held by other threads with the type of error detection lock |
Calling this function to unlock the mutex. This function is a wrapper of the rt_mutex_release() function. When the thread completes the access of the shared resource, it should release the possessed mutex as soon as possible, so that other threads can acquire the mutex in time. Only a thread that already has a mutex can release it, and its holding count is decremented by one each time the mutex is released. When the mutex's holding count is zero (ie, the holding thread has released all holding operations), the mutex becomes available, and the thread waiting on the mutex is placed in a first-in-first-out manner. If the thread's run priority is promoted by the mutex lock, then when the mutex is released, the thread reverts to the priority before holding the mutex.
This program will initialize 2 threads, they have the same priority, 2 threads will call the same printer() function to output their own string, the printer() function will output only one character at a time, then sleep for 1 second, call printer The thread of the () function also sleeps. If you do not use a mutex, thread 1 prints a character, and after hibernation, thread 2 is executed, and thread 2 prints a character, so that the thread 1 and thread 2 strings cannot be completely printed, and the printed string is confusing. If a mutex is used to protect the print function printer() shared by 2 threads, thread 1 takes the mutex and executes the printer() print function to print a character, then sleeps for 1 second, which is switched to thread 2 because The nick lock has been locked by thread 1, and thread 2 will block until thread 1 of thread 1 is fully released and the thread 2 is woken up after the mutex is actively released.
A condition variable is actually a semaphore used for synchronization between threads. A condition variable is used to block a thread. When a condition is met, a condition is sent to the blocked thread. The blocking thread is woken up. The condition variable needs to be used with the mutex. The mutex is used to protect the shared data.
Condition variables can be used to inform shared data status. For example, if a thread that processes a shared resource queue finds that the queue is empty, then the thread can only wait until one node is added to the queue. After adding, a conditional variable signal is sent to activate the waiting thread.
The main operations of the condition variable include: calling pthread_cond_init()
to initialize the condition variable, calling pthread_cond_destroy()
to destroy a condition variable, calling pthread_cond_wait()
to wait for a condition variable, and calling pthread_cond_signal()
to send a condition variable.
Each condition variable corresponds to a condition variable control block, including some information about the operation of the condition variable. A pthread_cond_t
condition variable control block needs to be defined before initializing a condition variable. pthread_cond_t
is a redefinition of the pthread_cond
structure type, defined in the pthread.h header file.
Parameter | Description |
---|---|
cond | Conditional variable handle, cannot be NULL |
attr | Pointer to the condition variable property, if NULL then use the default property value |
return | —— |
0 | succeeded |
EINVAL | Invalid parameter |
This function initializes the cond
condition variable and sets its properties according to the condition variable property pointed to by attr
, which is a wrapper of the rt_sem_init()
function, based on semaphore implementation. The condition variable is not available after successful initialization.
You can also statically initialize a condition variable with the macro PTHREAD_COND_INITIALIZER by: pthread_cond_t cond = PTHREAD_COND_INITIALIZER
(structural constant), which is equivalent to specifying NULL when calling pthread_cond_init()
.
Attr General setting NULL use the default value, as described in the thread advanced programming chapter.
Parameter | Description |
---|---|
cond | Conditional variable handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EPERM | Mutexes are not nested locks, but threads call this function repeatedly |
EBUSY | Condition variables are being used |
This function destroys the cond
condition variable, and the cond
is uninitialized after destruction. The attribute and control block parameters of the condition variable will not be valid after destruction, but can be reinitialized by calling pthread_cond_init()
or statically.
Before destroying a condition variable, you need to make sure that no threads are blocked on the condition variable and will not wait to acquire, signal, or broadcast.
Parameter | Description |
---|---|
cond | Conditional variable handle, cannot be NULL |
mutex | Pointer to the mutex control block, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
This function gets the cond
condition variable in blocking mode. The thread needs to lock the mutex before waiting for the condition variable. This function first determines whether the condition variable is available. If it is not available, initializes a condition variable, then unlocks the mutex and then tries to acquire a semaphore when the semaphore's value is greater than zero, it indicates that the semaphore is available, the thread will get the semaphore, and the condition variable will be obtained, and the corresponding semaphore value will be decremented by 1. If the value of the semaphore is equal to zero, indicating that the semaphore is not available, the thread will block until the semaphore is available, after which the mutex will be locked again.
Parameter | Description |
---|---|
cond | Conditional variable handle, cannot be NULL |
mutex | Pointer to the mutex control block, cannot be NULL |
abstime | The specified wait time in operating system clock tick (OS Tick) |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EPERM | Mutexes are not nested locks, but threads call this function repeatedly |
ETIMEDOUT | time out |
The only difference between this function and the pthread_cond_wait()
function is that if the condition variable is not available, the thread will be blocked for the abstime
duration. After the timeout, the function will directly return the ETIMEDOUT error code and the thread will be woken up to the ready state.
Parameter | Description |
---|---|
cond | Conditional variable handle, cannot be NULL |
return | —— |
0 | Succeeded |
This function sends a signal and wakes up only one thread waiting for the cond
condition variable, which encapsulates the rt_sem_release() function, which is to send a semaphore. When the value of the semaphore is equal to zero, and a thread waits for this semaphore, it will wake up the first thread waiting in the queue of the semaphore to get the semaphore. Otherwise the value of the semaphore will be increased by 1.
Parameter | Description |
---|---|
cond | Conditional variable handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
Calling this function will wake up all threads waiting for the cond
condition variable.
This example is a producer consumer model with a producer thread and a consumer thread that have the same priority. The producer will produce a number every 2 seconds, put it in the list pointed to by the head
, and then call pthread_cond_signal() to send signal to the consumer thread to inform the consumer that there is data in the thread list. The consumer thread calls pthread_cond_wait() to wait for the producer thread to send a signal.
Read-write locks are also known as multi-reader single-writer locks. The read-write lock divides the visitors of the shared resource into readers and writers. The reader only reads and accesses the shared resources, and the writer needs to write the shared resources. Only one thread can occupy the read-write lock of the write mode at the same time, but there can be multiple threads simultaneously occupying the read-write lock of the read mode. Read-write locks are suitable for reading data structures much more often than writes because read patterns can be shared when locked, and write mode locks are exclusive.
Read-write locks are usually implemented based on mutex locks and condition variables. A thread can lock a read-write lock several times, and it must also have the corresponding number of unlocks.
The main operations of the read-write lock include: calling pthread_rwlock_init()
to initialize a read-write lock, the write thread calling pthread_rwlock_wrlock()
to lock the read-write lock, and the read thread calling pthread_rwlock_rdlock()
to lock the read-write lock , when this read-write lock is not required, calling pthread_rwlock_destroy()
to destroys the read-write lock.
Each read-write lock corresponds to a read-write lock control block, including some information about the operation of the read-write lock. pthread_rwlock_t
is a redefinition of the pthread_rwlock
data structure, defined in the pthread.h
header file. Before creating a read-write lock, you need to define a data structure of type pthread_rwlock_t
.
Parameter | Description |
---|---|
rwlock | Read-write lock handle, cannot be NULL |
attr | Pointer to the read-write lock property, RT-Thread does not use this variable |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
This function initializes an rwlock
read-write lock. This function initializes the semaphore and condition variables of the read-write lock control block with default values, and the associated count parameter is initially 0. The read-write lock after initialization is in an unlocked state.
You can also use the macro PTHREAD_RWLOCK_INITIALIZER to statically initialize the read-write lock by: pthread_rwlock_t mutex = PTHREAD_RWLOCK_INITIALIZER
(structural constant), which is equivalent to specifying attr
a NULL value when calling pthread_rwlock_init().
attr
generally sets NULL to the default value, as described in the chapter on advanced threading.
Parameter | Description |
---|---|
rwlock | Read-write lock handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EBUSY | The read-write lock is currently being used or has a thread waiting for the read-write lock |
EDEADLK | Deadlock |
This function destroys a rwlock
read-write lock, which destroys the mutex and condition variables in the read-write lock. After the destruction, the properties of the read-write lock and the control block parameters will not be valid, but you can call pthread_rwlock_init() or re-initialize the read-write lock in static mode.
Parameter | Description |
---|---|
rwlock | Read-write lock handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EDEADLK | Deadlock |
The reader thread can call this function to read-lock the rwlock
read-write lock. If the read-write lock is not write-locked and no writer thread is blocked on the read-write lock, the read-write thread will successfully acquire the read-write lock. If the read-write lock has been write-locked, the reader thread will block until the thread that executes the write-lock unlocks the read-write lock.
Parameter | Description |
---|---|
rwlock | Read-write lock handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EBUSY | The read-write lock is currently being used or has a thread waiting for the read-write lock |
EDEADLK | Deadlock |
This function differs from the pthread_rwlock_rdlock() function in that if the read-write lock is already write-locked, the reader thread is not blocked, but instead returns an error code EBUSY.
Parameter | Description |
---|---|
rwlock | Read-write lock handle, cannot be NULL |
abstime | The specified wait time in operating system clock tick (OS Tick) |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
ETIMEDOUT | Time out |
EDEADLK | Deadlock |
The difference between this function and the pthread_rwlock_rdlock() function is that if the read-write lock has been write-locked, the reader thread will block the specified abstime duration. After the timeout, the function will return the error code ETIMEDOUT and the thread will be woken up to the ready state.
Parameter | Description |
---|---|
rwlock | Read-write lock handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EDEADLK | Deadlock |
The writer thread calls this function to write-lock the rwlock
read-write lock. A write-lock read-write lock is similar to a mutex, and only one thread can write-lock a read-write lock at a time. If no thread locks the read-write lock, that is, the read-write lock value is 0, the writer thread that calls this function will write-lock the read-write lock, and other threads cannot acquire the read-write lock at this time. If there is already a thread locked the read-write lock, ie the read/write lock value is not 0, then the writer thread will be blocked until the read-write lock is unlocked.
Parameter | Description |
---|---|
rwlock | Read-write lock handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EBUSY | The read-write lock is currently Write-Locked or there are reader threads blocked on the read-write lock |
EDEADLK | Deadlock |
The only difference between this function and the pthread_rwlock_wrlock() function is that if a thread has locked the read-write lock, ie the read-write lock value is not 0, the writer thread that called the function will directly return an error code, and the thread will not be Blocked.
Parameter | Description |
---|---|
rwlock abstime | Read-write lock handle, cannot specify the wait time for NULL, the unit is the operating system clock beat (OS Tick) |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
ETIMEDOUT | Time out |
EDEADLK | Deadlock |
The only difference between this function and the pthread_rwlock_wrlock() function is that if a thread locks the read-write lock, that is, the read-write lock value is not 0, the calling thread blocks the specified abstime
duration. After the timeout, the function returns the error code ETIMEDOUT, and the thread will be woken up to the ready state.
Parameter | Description |
---|---|
rwlock | Read-write lock handle, cannot be NULL |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
EDEADLK | Deadlock |
This function unlocks the rwlock
read-write lock. A thread locks the same read-write lock multiple times and must have the same number of unlocks. If multiple threads wait for the read-write lock to lock after unlocking, the system will activate the waiting thread according to the first-in-first-out rule.
This program has two reader threads, one reader thread. The two reader threads read-lock the read-write lock first, then sleep for 2 seconds. This time the other reader threads can read-lock the read-write lock, and then read the shared data.
Barriers are a way to synchronize multithreading. Barrier means a barrier or railing that blocks multiple threads that arrive in the same railing until all threads arrived, then remove the railings and let them go at the same time. The thread that arrives first will block, and when all the threads that call the pthread_barrier_wait() function (the number equal to the count specified by the barrier initialization) arrive, the threads will enter the ready state from the blocked state and participate in the system scheduling again.
Barriers are implemented based on condition variables and mutex locks. The main operations include: calling pthread_barrier_init()
to initialize a barrier, and other threads calling pthread_barrier_wait()
. After all threads arrived, the thread wakes up to the ready state. Destroy a barrier by calling pthread_barrier_destroy() when the barrier will not be used.
Before creating a barrier, you need to define a pthread_barrier_t
barrier control block. pthread_barrier_t
is a redefinition of the pthread_barrier
structure type, defined in the pthread.h header file.
Parameter | Description |
---|---|
attr | Pointer to the barrier property, if passing NULL, use the default value. PTHREAD_PROCESS_PRIVATE must be used as a non-NULL value. |
barrier | Barrier handle |
count | The number of waiting threads specified |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
This function creates a barrier
barrier and initializes the conditional variables and mutex locks of the barrier control block according to the default parameters. The number of waiting threads specified after initialization is count
, and pthread_barrier_wait() must be called for count
threads.
attr generally sets NULL to the default value, as described in the chapter on thread advanced programming.
Parameter | Description |
---|---|
barrier | Barrier handle |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
This function destroys a barrier. The barrier's properties and control block parameters will not be valid after destruction, but can be reinitialized by calling pthread_barrier_init().
Parameter | Description |
---|---|
barrier | Barrier handle |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
This function synchronizes the threads waiting in front of the barrier and called by each thread. If the number of queue waiting threads is not 0, count will be decremented by 1. If the count is 0, indicating that all threads have reached the railing. All arriving threads will be woken up and re-entered into the ready state to participate in system scheduling. If count is not 0 after the decrease, it indicates that there is still threads that do not reach the barrier, and the calling thread will block until all threads reach the barrier.
This program will create 3 threads, initialize a barrier, and the barrier waits for 3 threads. 3 threads will call pthread_barrier_wait() to wait in front of the barrier. When all 3 threads are arrived, 3 threads will enter the ready state. The output count information is printed every 2 seconds.
Semaphores can be used for communication between processes and processes, or between in-process threads. Each semaphore has a semaphore value that is not less than 0, corresponding to the available amount of semaphore. Call sem_init() or sem_open() to assign an initial value to the semaphore . Call sem_post() to increment the semaphore value by 1. Call sem_wait() to decrement the semaphore value by 1. If the current semaphore is 0, call sem_wait(), the thread will suspended on the wait queue for this semaphore until the semaphore value is greater than 0 and is available.
Depending on the value of the semaphore (representing the number of available resources), POSIX semaphores can be divided into:
POSIX semaphores are also divided into named semaphores and unnamed semaphores:
The POSIX semaphore of the RT-Thread operating system is mainly based on a package of RT-Thread kernel semaphores, mainly used for communication between threads in the system. It is used in the same way as the semaphore of the RT-Thread kernel.
Each semaphore corresponds to a semaphore control block. Before creating a semaphore, you need to define a sem_t semaphore control block. Sem_t is a redefinition of the posix_sem structure type, defined in the semaphore.h header file.
The value of an unnamed semaphore is stored in memory and is generally used for inter-thread synchronization or mutual exclusion. Before using it, you must first call sem_init() to initialize it.
Parameter | Description |
---|---|
sem | Semaphore handle |
value | The initial value of the semaphore, indicating the available amount of semaphore resources |
pshared | RT-Thread unimplemented parameters |
return | —— |
0 | Succeeded |
-1 | Failed |
This function initializes an unnamed semaphore sem, initializes the semaphore related data structure according to the given or default parameters, and puts the semaphore into the semaphore list. The semaphore value after initialization is the given initial value. This function is a wrapper of the rt_sem_create() function.
Parameter | Description |
---|---|
sem | Semaphore handle |
return | —— |
0 | Succeeded |
-1 | Failed |
This function destroys an unnamed semaphore sem and releases the resources occupied by the semaphore.
A named semaphore whose value is stored in a file and is generally used for inter-process synchronization or mutual exclusion. Two processes can operate on named semaphores of the same name. The well-known semaphore implementation in the RT-Thread operating system is similar to the unnamed semaphore. It is designed for communication between threads and is similar in usage.
Parameter | Description |
---|---|
name | Semaphore name |
oflag | The way the semaphore is opened |
return | —— |
Semaphore handle | Succeeded |
NULL | Failed |
This function creates a new semaphore based on the semaphore name or opens an existing semaphore. The optional values for Oflag are 0
, O_CREAT
or O_CREAT|O_EXCL
. If Oflag is set to O_CREAT
, a new semaphore is created. If Oflag sets to O_CREAT|O_EXCL
, it returns NULL if the semaphore already exists, and creates a new semaphore if it does not exist. If Oflag is set to 0, a semaphore does not exist and NULL is returned.
Parameter | Description |
---|---|
name | Semaphore name |
return | —— |
0 | Succeeded |
-1 | Failed, semaphore does not exist |
This function looks up the semaphore based on the semaphore name, and marks the semaphore as a detached state if the semaphore is present. Then check the reference count. If the value is 0, the semaphore is deleted immediately. If the value is not 0, it will not be deleted until all threads holding the semaphore close the semaphore.
Parameter | Description |
---|---|
sem | Semaphore handle |
return | —— |
0 | Succeeded |
-1 | Failed |
When a thread terminates,it closes the semaphore it occupies. Whether the thread terminates voluntarily or involuntarily, this closing operation is performed. This is equivalent to a reduction of 1 in the number of semaphores held. If the holding count is zero after subtracting 1 and the semaphore is in separated state, the sem
semaphore will be deleted and the resources it occupies will be released.
Parameter | Description |
---|---|
sem | Semaphore handle, cannot be NULL |
sval | Save the obtained semaphore value address, cannot be NULL |
return | —— |
0 | Succeeded |
-1 | Failed |
This function obtains the value of the semaphore and saves it in the memory pointed to by sval
to know the amount of semaphore resources.
Parameter | Description |
---|---|
sem | Semaphore handle, cannot be NULL |
return | —— |
0 | Succeeded |
-1 | Failed |
The thread calls this function to get the semaphore, which is a wrapper of the rt_sem_take(sem,RT_WAITING_FOREVER)
function. If the semaphore value is greater than zero, the semaphore is available, the thread gets the semaphore, and the semaphore value is decremented by one. If the semaphore value is equal to 0, indicating that the semaphore is not available, the thread is blocked and entering the suspended state and queued in a first-in, first-out manner until the semaphore is available.
Parameter | Description |
---|---|
sem | Semaphore handle, cannot be NULL |
return | —— |
0 | Succeeded |
-1 | Failed |
This function is a non-blocking version of the sem_wait() function and is a wrapper of the rt_sem_take(sem,0)
function. When the semaphore is not available, the thread does not block, but returns directly.
Parameter | Description |
---|---|
sem | Semaphore handle, cannot be NULL |
abs_timeout | The specified wait time in operating system clock tick (OS Tick) |
return | —— |
0 | Succeeded |
-1 | Failed |
The difference between this function and the sem_wait()
function is that if the semaphore is not available, the thread will block the duration of abs_timeout
. After the timeout, the function returns -1, and the thread will be awakened from the blocking state to the ready state.
Parameter | Description |
---|---|
sem | Semaphore handle, cannot be NULL |
return | —— |
0 | Succeeded |
-1 | Failed |
This function will release a sem semaphore, which is a wrapper of the rt_sem_release() function. If the thread queue waiting for the semaphore is not empty, indicating that there are threads waiting for the semaphore, the first thread waiting for the semaphore will switch from the suspended state to the ready state, waiting for system scheduling. If no thread is waiting for the semaphore, the semaphore value will be incremented by one.
A typical case of semaphore usage is the producer consumer model. A producer thread and a consumer thread operate on the same block of memory, the producer fills the shared memory, and the consumer reads the data from the shared memory.
This program creates 2 threads, 2 semaphores, one semaphore indicates that the shared data is empty, one semaphore indicates that the shared data is not empty, and a mutex is used to protect the shared resource. After the producer thread produces the data, it will send a full_sem
semaphore to the consumer, informing the consumer that the thread has data available, and waiting for the empty_sem
semaphore sent by the consumer thread after 2 seconds of sleep. The consumer thread processes the shared data after the full_sem
sent by the producer, and sends an empty_sem
semaphore to the producer thread after processing. The program will continue to loop like this.
Message Queuing is another commonly used inter-thread communication method that accepts messages of unfixed length from threads or interrupt service routines and caches the messages in their own memory space. Other threads can also read the corresponding message from the message queue, and when the message queue is empty, the reader thread can be suspended. When a new message arrives, the suspended thread will be woken up to receive and process the message.
The main operations of the message queue include: creating or opening by the function mq_open()
, calling mq_send()
to send a message to the message queue, calling mq_receive()
to get a message from the message queue, and when the message queue is not in use, you can call mq_unlink()
to delete message queue.
POSIX message queue is mainly used for inter-process communication. The POSIX message queue of RT-Thread operating system is mainly based on a package of RT-Thread kernel message queue, mainly used for communication between threads in the system. It is used in the same way as the message queue of the RT-Thread kernel.
Each message queue corresponds to a message queue control block. Before creating a message queue, you need to define a message queue control block. The message queue control block is defined in the mqueue.h header file.
Parameter | Description |
---|---|
name | Message queue name |
oflag | Message queue open mode |
return | —— |
Message queue handle | Succeeded |
NULL | Failed |
This function creates a new message queue or opens an existing message queue based on the name of the message queue. The optional values for Oflag are 0
, O_CREAT
or O_CREAT\|O_EXCL
. If Oflag is set to O_CREAT
then a new message queue is created. If Oflag sets O_CREAT\|O_EXCL
, it returns NULL if the message queue already exists, and creates a new message queue if it does not exist. If Oflag is set to 0
, the message queue does not exist and returns NULL.
Parameter | Description |
---|---|
name | Message queue name |
return | —— |
0 | Succeeded |
-1 | Failed |
This function finds the message queue based on the message queue name name. If found, it sets the message queue to a detached state. If the hold count is 0, the message queue is deleted and the resources occupied by the message queue are released.
Parameter | Description |
---|---|
mqdes | Message queue handle |
return | —— |
0 | Succeeded |
-1 | Failed |
When a thread terminates,it closes the message queue it occupies. Whether the thread terminates voluntarily or involuntarily, this closure is performed. This is equivalent to the message queue holding count minus 1. If the holding count is 0 after the minus 1 and the message queue is in the separated state, the mqdes
message queue will be deleted and released the resources it occupies.
Parameter | Description |
---|---|
mqdes | Message queue handle, cannot be NULL |
sg_ptr | Pointer to the message to be sent, cannot be NULL |
msg_len | The length of the message sent |
msg_prio | RT-Thread unimplemented this parameter |
return | —— |
0 | Succeeded |
-1 | Failed |
This function is used to send a message to the mqdes
message queue, which is a wrapper of the rt_mq_send() function. This function adds the message pointed to by msg_ptr
to the mqdes
message queue, and the length of the message sent msg_len
must be less than or equal to the maximum message length set when the message queue is created.
If the message queue is full, that is, the number of messages in the message queue is equal to the maximum number of messages, the thread that sent the message or the interrupt program will receive an error code (-RT_EFULL).
Parameter | Description |
---|---|
mqdes | Message queue handle, cannot be NULL |
msg_ptr | Pointer to the message to be sent, cannot be NULL |
msg_len | The length of the message sent |
msg_prio | RT-Thread unimplemented parameters |
abs_timeout | The specified wait time in operating system clock tick (OS Tick) |
Parameter | —— |
0 | Succeeded |
-1 | Failed |
Currently RT-Thread does not support sending messages with the specified blocking time, but the function interface has been implemented, which is equivalent to calling mq_send().
Parameter | Description |
---|---|
mqdes | Message queue handle, cannot be NULL |
msg_ptr | Pointer to the message to be sent, cannot be NULL |
msg_len | The length of the message sent |
msg_prio | RT-Thread unimplemented parameters |
return | —— |
Message length | Succeeded |
-1 | Failed |
This function removes the oldest message from the mqdes
message queue and puts the message in the memory pointed to by msg_ptr
. If the message queue is empty, the thread that called the mq_receive() function will block until the message in the message queue is available.
Parameter | Description |
---|---|
mqdes | Message queue handle, cannot be NULL |
msg_ptr | Pointer to the message to be sent, cannot be NULL |
msg_len | The length of the message sent |
msg_prio | RT-Thread unimplemented parameters |
abs_timeout | The specified wait time in operating system clock tick (OS Tick) |
return | —— |
Message length | Succeeded |
-1 | Failed |
The difference between this function and the mq_receive() function is that if the message queue is empty, the thread will block the abs_timeout
duration. After the timeout, the function will return -1
, and the thread will be awakened from the blocking state to the ready state.
This program creates 3 threads, thread2 accepts messages from the message queue, and thread2 and thread3 send messages to the message queue.
This section provides a detailed introduction to some of the rarely used property objects and related functions.
The thread attributes implemented by RT-Thread include thread stack size, thread priority, thread separation status, and thread scheduling policy. pthread_create()
must initialize the property object before using the property object. APIs such as setting thread properties should be called before the thread is created. Changes of thread attributes do not affect the threads that have been created.
The thread attribute structure pthread_attr_t
is defined in the pthread.h header file. The thread attribute structure is as follows:
The thread property initialization and deinitialization functions are as follows:
Parameter | Description |
---|---|
attr | Pointer to the thread property |
return | —— |
0 | Succeeded |
Using the pthread_attr_init() function initializes the thread attribute structure attr
with the default value, which is equivalent to setting the parameter to NULL when calling the thread initialization function. You need to define a pthread_attr_t
attribute object before use. This function must be called before the pthread_create() function.
The pthread_attr_destroy() function deinitializes the property pointed to by attr
and can then reinitialize this property object by calling the pthread_attr_init() function again.
Setting or getting the separation state of a thread is as follows. By default, the thread is non-separated.
Parameter | Description |
---|---|
attr | Pointer to the thread property |
state | Thread detached state |
return | —— |
0 | Succeeded |
The thread separation state property value state can be PTHREAD_CREATE_JOINABL
(non-detached) and THREAD_CREATE_DETACHED
(detached).
The detached state of a thread determines how a thread reclaims the resources it occupies after the end of its run. There are two types of thread separation: joinable or detached. When the thread is created, you should call pthread_join() or pthread_detach() to reclaim the resources occupied by the thread after it finishes running. If the thread's detached state is joinable, other threads can call the pthread_join() function to wait for the thread to finish and get the thread return value, and then reclaim the resources occupied by the thread. A thread with a detached state cannot be joined by another thread. Immediately after the end of its operation, the system resources are released.
Setting \ Obtaining thread scheduling policy function is as follows:
Only the function interface is implemented. The default different priorities are based on priority scheduling, and the same priority time slice polling scheduling
Set / Obtain the thread's priority function as follows:
Parameter | Description |
---|---|
attr | Pointer to the thread property |
param | Pointer to the dispatch parameter |
return | —— |
0 | Succeeded |
The pthread_attr_setschedparam()
function sets the priority of the thread. Use param
to set the thread priority.
Parameter : The struct sched_param
is defined in sched.h and has the following structure:
The member sched_paraority
of the sched_param
controls the priority value of the thread.
Set / Obtain the stack size of a thread is as follows:
Parameter | Description |
---|---|
attr | Pointer to the thread property |
stack_size | Thread stack size |
return | —— |
0 | Succeeded |
The pthread_attr_setstacksize()
function sets the stack size in bytes. Stack space address alignment is required on most systems (for example, the ARM architecture needs to be aligned to a 4-byte address).
Set / Obtain the stack address and stack size of a thread is as follows:
Parameter | Description |
---|---|
attr | Pointer to the thread property |
stack_size | Thread stack size |
stack_base | Thread stack address |
return | —— |
0 | Succeeded |
The function that sets / obtains the scope of the thread is as follows:
Parameter | Description |
---|---|
attr | Pointer to the thread property |
scope | Thread scope |
return | —— |
0 | scope is PTHREAD_SCOPE_SYSTEM |
EOPNOTSUPP | scope is PTHREAD_SCOPE_PROCESS |
EINVAL | scope is PTHREAD_SCOPE_SYSTEM |
This program will initialize 2 threads, they have a common entry function, but their entry parameters are not the same. The first thread created will use the provided attr
thread attribute, and the other thread will use the system default attribute. Thread priority is a very important parameter, so this program will modify the first created thread to have a priority of 8, and the system default priority of 24.
Cancellation is a mechanism that allows one thread to end other threads. A thread can send a cancel request to another thread. Depending on the settings, the target thread may ignore it and may end immediately or postpone it until the next cancellation point.
The cancellation request can be sent using the following function:
Parameter | Description |
---|---|
thread | Thread handle |
return | —— |
0 | Succeeded |
This function sends a cancel request to the thread
thread. Whether the thread will respond to the cancellation request and when it responds depends on the state and type of thread cancellation.
The cancellation request can be set using the following function:
Parameter | Description |
---|---|
state | There are two values: PTHREAD_CANCEL_ENABLE : Cancel enable. PTHREAD_CANCEL_DISABLE : Cancel disabled (default value when thread is created). |
oldstate | Save the original cancellation status |
return | —— |
0 | Succeeded |
EINVAL | state is not PTHREAD_CANCEL_ENABLE or PTHREAD_CANCEL_DISABLE |
This function sets the cancel state and is called by the thread itself. Canceling the enabled thread will react to the cancel request, and canceling the disabled thread will not react to the cancel request.
You can use the following function to set the cancellation type, which is called by the thread itself:
Parameter | Description |
---|---|
type | There are 2 values: PTHREAD_CANCEL_DEFFERED : After the thread receives the cancellation request, it will continue to run to the next cancellation point and then end. (Default value when thread is created) .PTHREAD_CANCEL_ASYNCHRONOUS : The thread ends immediately. |
oldtype | Save the original cancellation type |
return | —— |
0 | Succeeded |
EINVAL | state is neither PTHREAD_CANCEL_DEFFERED nor PTHREAD_CANCEL_ASYNCHRONOUS |
The cancellation point can be set using the following function:
This function creates a cancellation point where the thread is called. Called primarily by a thread that does not contain a cancellation point, it can respond to a cancellation request. This function does not work if pthread_testcancel() is called while the cancel state is disabled.
The cancellation point is where the thread ends when it accepts the cancellation request. According to the POSIX standard, system calls that cause blocking, such as pthread_join(), pthread_testcancel(), pthread_cond_wait(), pthread_cond_timedwait(), and sem_wait(), are cancellation points.
All cancellation points included in RT-Thread are as follows:
This program creates 2 threads. After thread2 starts running, it sleeps for 8 seconds. Thread1 sets its own cancel state and type, and then prints the run count information in an infinite loop. After thread2 wakes up, it sends a cancel request to thread1, and thread1 ends the run immediately after receiving the cancel request.
It can be initialized once using the following function:
Parameter | Description |
---|---|
once_control | Control variable |
init_routine | Execute function |
return | —— |
0 | Succeeded |
Sometimes we need to initialize some variables only once. If we do multiple initialization procedures, it will get an error. In traditional sequential programming, one-time initialization is often managed by using Boolean variables. The control variable is statically initialized to 0, and any code that relies on initialization can test the variable. If the variable value is still 0, it can be initialized and then set the variable to 1. Codes that are checked later will skip initialization.
The thread cleanup function interface:
Parameter | Description |
---|---|
execute | 0 or 1, determin whether to execute the cleanup function |
routine | Pointer to the cleanup function |
arg | The parameter passed to the cleanup function |
pthread_cleanup_push() puts the specified cleanup routine
into the thread's cleanup function list. pthread_cleanup_pop() takes the first function from the header of the cleanup function list. If execute
is a non-zero value, then this function is executed.
Parameter | Description |
---|---|
pthread_t | Thread handle |
return | —— |
0 | Not equal |
1 | Equal |
pthread_self() returns the handle of the calling thread.
Parameter | Description |
---|---|
policy | 2 values are optional: SCHED_FIFO, SCHED_RR |
sched_get_priority_min() returns a value of 0, with the highest priority in RT-Thread and sched_get_priority_max() with the lowest priority.
The mutex properties implemented by RT-Thread include the mutex type and the mutex scope.
Parameter | Description |
---|---|
attr | Pointer to the mutex attribute object |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
The pthread_mutexattr_init() function initializes the property object pointed to by attr
with the default value, which is equivalent to setting the property parameter to NULL when calling the pthread_mutex_init() function.
The pthread_mutexattr_destroy() function will initialize the property object pointed to by attr
and can be reinitialized by calling the pthread_mutexattr_init() function.
Parameter | Description |
---|---|
type | Mutex type |
pshared | There are 2 optional values: PTHREAD_PROCESS_PRIVATE : The default value, used to synchronize only threads in the process. PTHREAD_PROCESS_SHARED : Used to synchronize threads in this process and other processes. |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
Parameter | Description |
---|---|
type | Mutex type |
attr | Pointer to the mutex attribute object |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
The type of mutex determines how a thread behaves when it acquires a mutex. RT-Thread implements three mutex types:
Use the default value PTHREAD_PROCESS_PRIVATE to initialize the condition variable attribute attr to use the following function:
Parameter | Description |
---|---|
attr | Pointer to a condition variable property object |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
Parameter | Description |
---|---|
attr | Pointer to a condition variable property object |
return | —— |
0 | Succeeded |
EINVAL | Invalid parameter |
Parameter | Description |
---|---|
attr | Pointer to the read-write lock property |
return | —— |
0 | Succeeded |
-1 | Invalid parameter |
This function initializes the read-write lock attribute attr
with the default value PTHREAD_PROCESS_PRIVATE.
Parameter | Description |
---|---|
attr | Pointer to the read-write lock property |
pshared | Pointer to the scope of the read-write lock |
return | —— |
0 | Succeeded |
-1 | Invalid parameter |
The memory pointed to by pshared is saved as PTHREAD_PROCESS_PRIVATE.
Parameter | Description |
---|---|
attr | Pointer to the barrier property |
return | —— |
0 | Succeeded |
-1 | Invalid parameter |
The modified function initializes the barrier attribute attr
with the default value PTHREAD_PROCESS_PRIVATE.
Parameter | Description |
---|---|
attr | Pointer to the barrier property |
pshared | Pointer to save barrier scope data |
return | —— |
0 | Succeeded |
-1 | Invalid parameter |
The message queue attribute control block is as follows:
Parameter | Description |
---|---|
mqdes | Pointer to the message queue control block |
mqstat | Pointer to save the get data |
return | —— |
0 | Succeeded |
-1 | Invalid parameter |