Shulou(Shulou.com)06/01 Report--

This article mainly explains "how to use LiteOS mutex". Friends who are interested may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to use LiteOS mutex.

1. LiteOS mutex 1.1. Mutex lock

In a multitasking environment, there are often application scenarios in which multiple tasks compete for the same shared resource, and mutexes can be used to protect shared resources to achieve exclusive access. Mutex (mutex), also known as mutex semaphore, is a special binary semaphore, which is used to realize the exclusive processing of shared resources. In addition, the mutex provided by Huawei LiteOS solves the priority reversal problem through the priority inheritance algorithm.

1.2. The use of mutexes

In a multitasking environment, there will be scenarios in which multiple tasks access the same common resources, while some common resources are not shared and require exclusive processing of tasks.

How can mutexes avoid this conflict?

At any given time, there are only two states of mutex: unlocking and locking.

When a task is held, the mutex is locked, and the task takes ownership of the mutex. When the task releases it, the mutex is unlocked and the task loses ownership of the mutex. When a task holds a mutex, other tasks can no longer unlock or hold the mutex.

Then, when a mutex is locked, other tasks will be blocked if they want to access the common resource, and other tasks will not be able to re-access the common resource until the mutex is released by the task holding the lock. at this time, the mutex is locked again, thus ensuring that only one task is accessing the common resource at the same time, ensuring the integrity of the operation of the common resource.

1.3. Usage scenarios of mutexes

Mutexes provide a mutex mechanism between tasks to prevent two tasks from accessing the same shared resources at the same time.

In addition, mutexes can also be used to prevent priority reversal when multitasking is synchronized.

two。 Mutex API

The mutex module in Huawei LiteOS system provides users with the function of creating / deleting mutex and acquiring / releasing mutex.

The mutex API provided in the Huawei LiteOS system starts with LOS, but it is complicated to use these API. Therefore, we use the unified API interface provided by Huawei IoT Link SDK for experiments. The underlying layer of these interfaces has been implemented using API provided by LiteOS, which is more concise for users. The API list is as follows:

The api API of osal is declared in, and the header file needs to be included to use the related API. For more information on the parameters of the function, please refer to the declaration of the header file.

The relevant interfaces are defined in osal.c, and the LiteOS-based interfaces are implemented in the liteos_imp.c file:

API name function description osal_mutex_create creates mutex osal_mutex_del deletes mutex osal_mutex_lock acquires mutex (lock) osal_mutex_unlock releases mutex (unlock) 2.1. Osal_mutex_create

The osal_mutex_create API is used to create a mutex. The interface prototype is as follows:

Bool_t osal_mutex_create (osal_mutex_t * mutex) {bool_t ret = false; if ((NULL! = s_os_cb) & & (NULL! = sroomosroomcb-> ops) & & (NULL! = slicosroomcb-> ops- > mutex_create)) {ret = scompresosroomcb-> ops- > mutex_create (mutex);} return ret;}

The parameters of this API are described in the following table:

Parameter describes the address return value of the mutex mutex index ID false-creation failure return value true-successfully created 2. 2. Osal_mutex_del

API osal_mutex_del is used to delete a mutex. The prototype of the API is as follows:

Bool_t osal_mutex_del (osal_mutex_t mutex) {bool_t ret = false; if ((NULL! = s_os_cb) & & (NULL! = sroomosroomcb-> ops) & & (NULL! = slicosroomcb-> ops- > mutex_del)) {ret = scompresosroomcb-> ops- > mutex_del (mutex);} return ret;}

The parameters of this API are described in the following table:

Parameter description mutex mutex index ID return value false-delete failure return value true-delete success 2.3. Osal_mutex_lock

The osal_mutex_lock API is used to acquire a mutex. The interface prototype is as follows:

Bool_t osal_mutex_lock (osal_mutex_t mutex) {bool_t ret = false; if ((NULL! = s_os_cb) & & (NULL! = sroomosroomcb-> ops) & & (NULL! = slicosroomcb-> ops- > mutex_lock)) {ret = scompresosroomcb-> ops- > mutex_lock (mutex);} return ret } Parameter description mutex mutex index ID return value false-application failed return value true-application success 2.4. Osal_mutex_unlock

The osal_mutex_unlock interface is used to release a mutex, and if there is a task blocking waiting for the mutex, it wakes up the earliest blocked task, which enters the ready state and is scheduled.

The interface prototype is as follows:

Bool_t osal_mutex_unlock (osal_mutex_t mutex) {bool_t ret = false; if ((NULL! = s_os_cb) & & (NULL! = sroomosroomcb-> ops) & & (NULL! = slicosroomcb-> ops- > mutex_unlock)) {ret = scompresosroomcb-> ops- > mutex_unlock (mutex);} return ret;}

The parameters of this API are described in the following table:

Parameter description mutex mutex index ID return value false-release failed return value true-release successful 3. Hands-on experiment-- the content of resource protection experiment using mutex

In this experiment, we will create two tasks, a low priority task task1 and a high priority task task2. The two tasks lock, operate and unlock the shared resources in turn, and observe the operation of the two tasks in the serial port terminal.

Experimental code

First of all, open the HelloWorld project used in the previous article, and carry out experiments based on this project.

Right-click the Demo folder and create a new folder called osal_kernel_demo to store the kernel's experimental files (ignore this step if you already have one).

Next, create a new experimental file, osal_mutex_demo.c, in this folder, and start writing code:

/ * to use the osal interface, you need to include the header file * / # include / * Task priority macro definition (priority of shell task is 10) * / # define USER_TASK1_PRI 12 / / low priority # define USER_TASK2_PRI 11 / / High priority / * shared resources * / uint32_t public_value = 0ram * mutex index ID * / osal_mutex_t public_value_mutex / * Task task1 entry function * / static int user_task1_entry () {while (1) {/ * attempt to acquire mutex * / if (true = = osal_mutex_lock (public_value_mutex)) {/ * acquire mutex and operate on shared resources * / printf ("\ r\ ntask1: lock a mutex.\ r\ n") Public_value + = 10; printf ("task1: public_value =% ld.\ r\ n", public_value); / * release the mutex * / printf ("task1: unlock a mutex.\ r\ n\ r\ n") after the operation on the shared resource is completed; osal_mutex_unlock (public_value_mutex) / * the task ends if the condition is met * / if (public_value > 100) break;}} / * while (1) the execution ends, so the return value * / return 0 is required. } / * Task task2 entry function * / static int user_task2_entry () {while (1) {/ * attempt to acquire mutex * / if (true = = osal_mutex_lock (public_value_mutex)) {/ * acquire mutex and operate on shared resources * / printf ("\ r\ ntask2: lock a mutex.\ r\ n") Public_value + = 5; printf ("task2: public_value =% ld.\ r\ n", public_value); / * release the mutex * / printf ("task2: unlock a mutex.\ r\ n\ r\ n") after the operation on the shared resource is completed; osal_mutex_unlock (public_value_mutex) / * if the condition is met, the task ends * / if (public_value > 90) break; / * has a higher priority. You need to hang for a while and let task1 acquire the mutex, otherwise task2 will lock again, resulting in deadlock * / osal_task_sleep (10). }} / * while (1) will finish execution, so you need to return the value * / return 0;} / * the standard demo startup function. Do not modify the function name, otherwise it will affect the next experiment * / int standard_app_demo_main () {/ * create a mutex public_value_mutex * / osal_mutex_create (& public_value_mutex) / * create task task1 * / osal_task_create ("user_task1", user_task1_entry,NULL,0x400,NULL,USER_TASK1_PRI); / * create task task2 * / osal_task_create ("user_task2", user_task2_entry,NULL,0x400,NULL,USER_TASK2_PRI); return 0;}

After the writing is complete, add the osal_mutex_demo.c file we wrote to the makefile and add the compilation of the entire project:

Here is a relatively simple way to directly modify the user_demo.mk configuration file under the Demo folder and add the following code:

# example for osal_mutex_demoifeq ($(CONFIG_USER_DEMO), "osal_mutex_demo") user_demo_src = ${wildcard $(TOP_DIR) / targets/STM32L431_BearPi/Demos/osal_kernel_demo/osal_mutex_demo.c} endif

Add location as shown in the figure:

This code means:

If the value defined by the CONFIG_USER_DEMO macro is osal_mutex_demo, the osal_mutex_demo.c file is added to makefile for compilation.

So, how do you configure the CONFIG_USER_DEMO macro definition? You can configure it at the end of the .sdkconfig file in the project root directory:

Because we modified the mk configuration file, click the recompile button to compile, and when the compilation is complete, click the download button to burn the program.

Experimental phenomenon

After the program is burned, you can see that the program has started to run, and the output of the experiment can be seen in the serial terminal:

Linkmain:V1.2.1 AT 11:30:59 ON Nov 28 2019WELCOME TO IOT_LINK SHELLLiteOS:/ > task2: lock a mutex.task2: public_value = 5.task2: unlock a mutex.task1: lock a mutex.task1: public_value = 15.task1: unlock a mutex.task1: lock a mutex.task1: public_value = 25.task1: unlock a mutex.task2: lock a mutex.task2: public_value = 30.task2: unlock a mutex.task1: lock a mutex.task1: public_value = 40.task1: Unlock a mutex.task1: lock a mutex.task1: public_value = 50.task1: unlock a mutex.task2: lock a mutex.task2: public_value = 55.task2: unlock a mutex.task1: lock a mutex.task1: public_value = 65.task1: unlock a mutex.task1: lock a mutex.task1: public_value = 75.task1: unlock a mutex.task2: lock a mutex.task2: public_value = 80.task2: unlock a mutex.task1: lock a mutex.task1: public_value = 90.task1: Unlock a mutex.task1: lock a mutex.task1: public_value = 100.task1: unlock a mutex.task2: lock a mutex.task2: public_value = 105.task2: unlock a mutex.

As you can see, after the system starts, the version number is printed first, the priority of the serial port shell is 10, the shell information is printed first, and then the task1 is created first, but the priority is low, so the created task2 is preemptively executed, the task2 acquires the mutex, operates on the shared resource, unlocks it after the operation, and then actively suspends, task1 acquires the mutex, performs another operation on the shared resource, and unlocks the shared resource after the operation. During the task1 operation, the task2 has already been suspended, but the mutex cannot be acquired, so the wait is suspended, and after the task1 is unlocked, the blocked task2 is awakened to execute.

At this point, I believe you have a deeper understanding of "how to use LiteOS mutexes". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.