Task processing method and device based on mutual exclusion lock and storage medium
By configuring priority protection attributes and waiting queue management in the mutex of embedded operating system, the priority reversal problem when threads lock mutexes is solved, and the stability and response speed of the system are improved.
Patent Information
- Application Number
- CN202411528536.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-29
- Publication Date
- 2025-02-25
AI Technical Summary
In an embedded operating system, when multiple threads try to lock the same mutex at the same time, priority reversal problems may be caused, resulting in high-priority threads being blocked by low-priority threads and delayed response.
By configuring the priority protection attribute in the lock properties of the mutex, it allows the priority of the low-priority thread to be raised to a high priority, and add the threads to the waiting queue when the mutex is locked, assigning the mutex in priority order.
It effectively avoids priority reversal, ensures that high-priority tasks can be executed in a timely manner, and improves the stability and response speed of the system.
Smart Images
Figure CN119512770A_ABST
Abstract
Description
Technical Field
[0001] Embodiments of the present application relate to the field of embedded real-time operation technology, and in particular, to a task processing method, device and storage medium based on a mutex lock. Background Art
[0002] A mutex is a synchronization mechanism used to protect shared resources from concurrent access. It provides an exclusive way to ensure that only one thread can access the protected resource at a given time. The basic principle is that before accessing a shared resource, a thread must first acquire a mutex. If the mutex is not currently held by another thread, the thread can acquire the lock and continue to execute the critical section code. If the mutex is already held or occupied by another thread, the current thread will be blocked until the mutex is released.
[0003] In an embedded operating system, multiple threads may need to access shared resources, which is usually achieved through mutex locks.
[0004] However, when multiple threads try to lock the same mutex at the same time, it may cause priority inversion problem, that is, a high-priority thread may be blocked by a low-priority thread, resulting in response delay. Summary of the invention
[0005] The embodiments of the present application provide a task processing method, device and storage medium based on a mutex lock, so as to at least solve the problem of priority inversion that is prone to occur in the related art.
[0006] According to one aspect of an embodiment of the present application, a task processing method based on a mutex lock is provided, which is applied to an embedded operating system. The embedded operating system is configured with a mutex lock corresponding to a shared resource. The mutex lock allows configuration of at least one lock attribute, including: when a first thread is about to access a shared resource, obtaining the working state of the mutex lock; the first thread is a thread of a first task to be executed in the embedded operating system; when the working state of the mutex lock is an unlocked state, the lock attribute configured by the mutex lock includes a priority protection attribute, and the priority of the first thread is lower than the first priority, the mutex lock is assigned to the first thread, the priority of the first thread is increased to the first priority, and the first task is executed according to the first priority; when the working state of the mutex lock is a locked state, and the lock attribute configured by the mutex lock does not include a recursive attribute, the first thread is added to a first waiting queue with the mutex lock; according to the order of the first thread in the first waiting queue, the mutex lock is assigned to the first thread, and the first task is executed according to the priority of the first thread.
[0007] According to another aspect of an embodiment of the present application, a task processing device for a mutex lock is provided, which is applied to an embedded operating system. The embedded operating system is configured with a mutex lock corresponding to a shared resource, and the mutex lock allows configuration of at least one lock attribute, including: an acquisition module, used to acquire the working state of the mutex lock when a first thread is about to access the shared resource; the first thread is a thread of a first task to be executed in the embedded operating system; a first increase module, used to assign the mutex lock to the first thread, increase the priority of the first thread to the first priority, and execute the first task according to the first priority when the working state of the mutex lock is an unlocked state, the lock attribute configured by the mutex lock includes a priority protection attribute, and the priority of the first thread is lower than the first priority; a queue adding module, used to add the first thread to a first waiting queue with the mutex lock when the working state of the mutex lock is a locked state and the lock attribute configured by the mutex lock does not include a recursive attribute; a first execution module, used to assign the mutex lock to the first thread according to the order of the first thread in the first waiting queue, and execute the first task according to the priority of the first thread.
[0008] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the steps in any one of the above method embodiments are implemented.
[0009] According to another aspect of the embodiments of the present application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of any of the above method embodiments when executing the computer program.
[0010] According to another aspect of the embodiments of the present application, a computer program product or a computer program is also provided, the computer program product or the computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium. The processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device performs the steps in any of the above method embodiments.
[0011] Through this application, when the first thread is waiting to access a shared resource, and the working state of the mutex lock is unlocked and the lock attribute configured by the mutex lock includes a priority protection attribute, the priority protection attribute allows the first thread to be directly promoted to the specified first priority, ensuring that even if the thread holding the lock has a lower priority, the first thread can complete the execution of the task first, avoiding priority flipping and improving the stability and reliability of the system. When the first thread attempts to acquire an occupied non-recursive mutex lock, the threads are sorted in the correct order through the first waiting queue, which can optimize task scheduling and ensure that the tasks in the thread are reasonably executed. BRIEF DESCRIPTION OF THE DRAWINGS
[0012] Figure 1 is a hardware structure block diagram of a mobile terminal according to an optional task processing method based on a mutex lock according to an embodiment of the present application;
[0013] Figure 2 is a flowchart of an optional mutex-based task processing method according to an embodiment of the present application;
[0014] Figure 3 is an optional flowchart of acquiring a mutex lock according to an embodiment of the present application;
[0015] Figure 4 is an optional flowchart of releasing a mutex lock according to an embodiment of the present application;
[0016] Figure 5 is a structural block diagram of an optional task processing device based on a mutex lock according to an embodiment of the present application;
[0017] Figure 6 It is a block diagram of a computer system structure of an optional electronic device according to an embodiment of the present application. DETAILED DESCRIPTION
[0018] The embodiments of the present application will be described in detail below with reference to the accompanying drawings and in combination with the embodiments.
[0019] It should be noted that the terms "first", "second", etc. in the specification and claims of this application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence.
[0020] The method embodiment provided in the embodiment of the present application can be executed in a mobile terminal, a computer terminal or a similar computing device. Taking running on a mobile terminal as an example, FIG1 is a hardware structure block diagram of a mobile terminal of an optional task processing method based on a mutex lock according to the embodiment of the present application. Figure 1 As shown, the mobile terminal may include one or more ( Figure 1 Only one is shown in the figure) a processor 102 (the processor 102 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA) and a memory 104 for storing data, wherein the mobile terminal may also include a transmission device 106 and an input / output device 108 for communication functions. It can be understood by those skilled in the art that Figure 1 The structure shown is for illustration only and does not limit the structure of the mobile terminal. Figure 1 More or fewer components as shown, or with Figure 1 Different configurations are shown.
[0021] The memory 104 can be used to store computer programs, for example, software programs and modules of application software, such as the computer program corresponding to the task processing method based on the mutex lock in the embodiment of the present application. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, that is, to implement the above method. The memory 104 may include a high-speed random access memory, and may also include a non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, the memory 104 may further include a memory remotely arranged relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.
[0022] The transmission device 106 is used to receive or send data via a network. The specific example of the above network may include a wireless network provided by a communication provider of the mobile terminal. In one example, the transmission device 106 includes a network adapter (Network Interface Controller, referred to as NIC), which can be connected to other network devices through a base station so as to communicate with the Internet. In one example, the transmission device 106 can be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.
[0023] In this embodiment, a task processing method based on a mutex lock running on the above mobile terminal is provided. Figure 2 The present invention is a flowchart of an optional mutex-based task processing method according to an embodiment of the present invention, which is applied to an embedded operating system. The embedded operating system is configured with a mutex corresponding to a shared resource. The mutex allows configuration of at least one lock attribute, such as Figure 2 As shown, the process includes the following steps:
[0024] Step S202, when a first thread is about to access a shared resource, obtaining a working state of a mutex lock; the first thread is a thread of a first task to be executed in the embedded operating system.
[0025] It should be noted that an embedded operating system is an operating system designed for embedded devices. It usually has a small memory footprint, efficient real-time response, and optimized support for specific hardware. In an embedded real-time operating system, resource management and task scheduling are key functions to ensure that the system can run efficiently and in real time under limited hardware resources. Shared resources refer to resources that can be accessed by multiple threads or processes in a multi-threaded or process environment, such as global variables, files, hardware devices, etc. Mutex locks are used to control the access of multiple threads to shared resources. Lock attributes refer to the configurable characteristics of a mutex lock, which determine the behavior of the mutex lock. According to the actual needs in the embedded operating system, the corresponding lock attributes can be configured for the mutex lock corresponding to the shared resource. Each mutex lock can be configured with at least one lock attribute. By configuring the lock attribute, the lock type of the mutex lock can be switched, that is, by configuring the lock attribute, the mutex lock can be configured as a mutex lock with a corresponding lock function. In specific practice, the lock attribute of the mutex lock can be set through the API (Application Programming Interface).
[0026] The working state of a mutex lock can include "unlocked" and "locked", indicating whether the mutex lock is currently held by a thread. When the mutex lock is in the unlocked state, any thread can try to acquire it; when the mutex lock is locked, other threads can try to acquire it only after the holder of the mutex lock releases the mutex lock. Threads are the basic units of scheduling and dispatching in the operating system. A process can contain multiple threads, and each thread has its own execution stack and state. The task in a thread usually refers to the code or program segment executed by the thread. A thread may have multiple codes or program segments, that is, a thread may have multiple tasks. Each thread may be executing different tasks, and these tasks may need to access shared resources, so they need to acquire the corresponding mutex lock.
[0027] Exemplarily, the first thread may be a thread of a first task to be executed in an embedded operating system. When the first thread attempts to access a shared resource, the working state of the mutex is obtained, which is generally an unlocked state or a locked state (i.e., a locked state). When the working state of the mutex is an unlocked state, it means that no other thread currently holds the mutex, so the first thread may try to obtain the lock and access the shared resource in an exclusive manner.
[0028] Step S204, when the working state of the mutex lock is unlocked, the lock attribute configured by the mutex lock includes a priority protection attribute, and the priority of the first thread is lower than the first priority, the mutex lock is assigned to the first thread, the priority of the first thread is increased to the first priority, and the first task is executed according to the first priority.
[0029] It should be noted that the working state of the mutex is unlocked, or in other words, the mutex is in idle state. A mutex is configured with at least one lock attribute. The priority protection attribute can be used to protect the thread that has acquired the mutex from being snatched away by another thread with a higher priority, that is, to protect the thread that has acquired the mutex.
[0030] Exemplarily, when the working state of the mutex lock is unlocked, the lock attributes of the mutex lock configuration are identified; when the lock attributes of the mutex lock configuration include ordinary attributes and do not include priority protection attributes, the mutex lock is acquired and the first task in the first thread is executed.
[0031] When the working state of the mutex lock is unlocked and the lock attribute configured by the mutex lock includes a priority protection attribute, the mutex lock is assigned to the first thread, and the priority of the first thread is identified. When the priority of the first thread is less than the first priority, the priority of the first thread is increased to the first priority, and the first task is executed according to the priority of the first thread. Specifically, when the working state of the mutex lock is unlocked and the lock attribute configured by the mutex lock includes a priority protection attribute, the first priority can be determined according to the priorities of all threads currently existing in the operating system. The first priority can be greater than or equal to the maximum value of the priorities of all currently existing threads, or can be the maximum value of a preset priority.
[0032] Step S206: When the working state of the mutex lock is the locked state and the lock attribute configured for the mutex lock does not include a recursive attribute, the first thread is added to a first waiting queue of the mutex lock.
[0033] It should be noted that the recursive attribute configured by the mutex is usually used to support recursive calls of threads in the critical section without causing deadlock. The working state of the mutex is the locked state, that is, the mutex is currently occupied.
[0034] Exemplarily, the first waiting queue can be used to record threads that need to wait for the mutex lock. When the working state of the mutex lock is the locked state and the lock attribute configured by the mutex lock does not include the recursive attribute, the first thread is added to the first waiting queue of the mutex lock.
[0035] Step S208: assigning a mutex lock to the first thread according to the order of the first thread in the first waiting queue, and executing the first task according to the priority of the first thread.
[0036] Exemplarily, the first waiting queue may record threads that need to wait for a mutex lock, and in the first waiting queue, threads that need to wait for a mutex lock are arranged in a certain order. After the mutex lock is unlocked, the mutex lock is allocated to the first thread according to the order of the first thread in the first waiting queue, and the first task in the first thread is executed.
[0037] Through the above steps, when the first thread is about to access a shared resource, the working state of the mutex lock is obtained; the first thread is the thread of the first task to be executed in the embedded operating system; when the working state of the mutex lock is an unlocked state, the lock attribute configured by the mutex lock includes a priority protection attribute, and the priority of the first thread is lower than the first priority, the mutex lock is allocated to the first thread, the priority of the first thread is increased to the first priority, and the first task is executed according to the first priority; when the working state of the mutex lock is a locked state, and the lock attribute configured by the mutex lock does not include a recursive attribute, the first thread is added to the first waiting queue with the mutex lock; according to the order of the first thread in the first waiting queue, the mutex lock is allocated to the first thread, and the first task is executed according to the priority of the first thread, thereby solving the problem of priority inversion that is prone to occur in the related art and improving the accuracy of task scheduling.
[0038] In an exemplary embodiment, after raising the priority of the first thread to the first priority, the method further includes:
[0039] When the first thread releases the mutex lock, the priority of the first thread is restored from the first priority to the priority before being increased.
[0040] Exemplarily, the first thread releases the mutex, that is, the task execution in the first thread is completed, and the working state of the corresponding mutex is unlocked. After the first thread releases the mutex, the priority of the first thread is restored from the first priority to the priority before the increase.
[0041] In practice, in a mutex with a priority protection attribute, the thread that acquires the mutex will release the mutex after executing the critical section code, and the priority of the corresponding thread will be automatically restored to its previous value without affecting the priority of other threads.
[0042] Through this embodiment, after the priority of the first thread is increased to the first priority, when the first thread releases the mutex lock, the priority of the first thread is restored to ensure that the priority management is temporary and maintain the fairness of the embedded operating system scheduling.
[0043] In an exemplary embodiment, the method further comprises:
[0044] When the working state of the mutex lock is a locked state and the lock attribute configured by the mutex lock includes a recursive attribute, determining whether the first thread and the second thread are the same thread, wherein the second thread is a thread that owns the mutex lock;
[0045] When the first thread and the second thread are the same thread, the first task is added to the second waiting queue, wherein the second waiting queue is a waiting queue for a mutex lock that is in a locked state and whose attribute information includes recursive mutex locks, and the second waiting queue is used to record different tasks of the thread that owns the mutex lock.
[0046] It should be noted that in order to use the recursive attribute reasonably and safely, some restrictions and management are required on the recursive characteristics of the mutex lock with recursive attributes to ensure its correctness and efficiency. For example, a recursive counter and an identifier ID will be set. The recursive counter is used to record the number of times the same thread acquires the lock. When the thread acquires the lock for the first time, the recursive counter is initialized to 1; each time the recursive call acquires the lock again, the recursive counter increments; when the thread releases the lock, the recursive counter decrements. Only when the recursive counter is reduced to 0 is the lock actually released, allowing other threads to acquire it. The identifier ID is used to identify the ID of the thread that acquires the mutex lock configured with recursive attributes.
[0047] Exemplarily, when the working state of the mutex is a locked state and the lock attribute of the mutex configuration includes a recursive attribute, it is determined that the mutex configured with recursiveness has been locked by the second thread, and the second thread is the thread that owns the mutex. Therefore, it is necessary to determine whether the first thread and the second thread are the same thread. When the first thread and the second thread are the same thread, the first task is added to the second waiting queue, wherein the second waiting queue is a waiting queue for the mutex in a locked state and whose attribute information includes recursiveness, and the second waiting queue is used to record different tasks of the thread that owns the mutex. When the first thread and the second thread are not the same thread, the first thread is added to the first waiting queue.
[0048] In specific practice, when the working state of the mutex is the locked state, the lock attribute configured by the mutex includes a recursive attribute, and the first thread and the second thread are the same thread, the recursive counter is incremented, for example: lock_cnt+1.
[0049] Through this embodiment, when the working state of the mutex lock is the locked state, the lock attribute configured by the mutex lock includes a recursive attribute, and the first thread and the second thread are the same thread, the first task is added to the second waiting queue, which can avoid deadlock caused by the same thread constantly acquiring the same mutex lock.
[0050] In an exemplary embodiment, after adding the first task to the second waiting queue, the method further includes:
[0051] Execute each task in the second waiting queue in sequence according to the order of the tasks in the second waiting queue until the second waiting queue is empty;
[0052] The mutex lock is assigned to the head thread in the first waiting queue, and the task corresponding to the head thread is executed according to the priority of the head thread.
[0053] It should be noted that when the second waiting queue is empty, it means that the mutex lock configured with recursiveness is in an unlocked state and can be locked by other threads. The order of tasks in the second waiting queue can be sorted according to the order in which the mutex lock is triggered by different tasks in the second thread. The head thread in the first waiting queue is the thread ranked first in the first waiting queue.
[0054] Exemplarily, after the first task is added to the second waiting queue, each task in the second waiting queue is executed in sequence according to the order of the tasks in the second waiting queue, until the second waiting queue is empty, and it is determined that the second thread releases the mutex lock configured with recursive attribution. At this time, the mutex lock is assigned to the head thread in the first waiting queue, and the task corresponding to the head thread is executed according to the priority of the head thread.
[0055] In specific practice, in the process of executing each task in the second waiting queue in sequence according to the order of tasks in the second waiting queue, the mutex lock configured with recursion will decrement the corresponding recursive count in sequence. Only when the recursive counter is reduced to 0, it means that the second waiting queue is empty.
[0056] Through this embodiment, based on the fact that the second waiting queue is empty, it is determined that the mutex lock configured with recursiveness is in an unlocked state, so that the mutex lock is allocated to the head thread in the first waiting queue, and the task corresponding to the head thread is executed according to the priority of the head thread, thereby reducing unnecessary scheduling delays and improving the overall efficiency of task execution.
[0057] In an exemplary embodiment, adding a first thread to a first waiting queue associated with a mutex includes:
[0058] The first thread is added to the first waiting queue according to a queue scheduling attribute of the first waiting queue, wherein the queue scheduling attribute is used to indicate an order in which threads in the first waiting queue acquire mutex locks.
[0059] It should be noted that the queue scheduling attributes can be the queuing rules and scheduling strategies when the threads are waiting to acquire the mutex lock. These attributes determine the queueing order of the threads in the first waiting queue, thereby affecting the timing of the threads acquiring the lock and executing the critical section code. The queue scheduling attributes are pre-configured for the first waiting queue according to the requirements in the embedded operating system. The queue scheduling attributes can be used to indicate the order in which the threads in the first waiting queue acquire the mutex lock.
[0060] Exemplarily, according to the queue scheduling attribute of the first waiting queue, the first thread is added to the first waiting queue, and the arrangement order of the threads in the first waiting queue is updated.
[0061] Through this embodiment, the threads in the first waiting queue are reasonably sorted according to the queue scheduling attribute of the first waiting queue, thereby indicating the order in which the threads in the first waiting queue acquire the mutex locks, thereby achieving fairer and more efficient scheduling.
[0062] In an exemplary embodiment, adding the first thread to the first waiting queue according to the queue scheduling attribute of the first waiting queue includes:
[0063] When the queue scheduling attribute is first-in-first-out, the first thread is added to the tail of the first waiting queue;
[0064] When the queue scheduling attribute is arranged according to thread priority, the first thread is added to the first waiting queue based on the priority of the first thread, wherein each thread in the first waiting queue is sorted in sequence according to the priority of the corresponding thread.
[0065] The queue scheduling attributes may include but are not limited to first-in-first-out and arrangement according to thread priority.
[0066] In practice, when the queue scheduling attribute is FIFO, thread A in the embedded real-time operating system needs to acquire a mutex lock, but the mutex lock is currently used by thread B. At this time, the thread scheduler detects that the queue scheduling attribute of the lock is FIFO (first in first out), so thread A will be added to the end of the first waiting queue until thread B releases the lock. Only then will thread A acquire the mutex lock and execute its critical section code according to its position in the queue (that is, the first waiting thread in the queue).
[0067] When the queue scheduling attribute is arranged according to thread priority, thread C is a high priority thread and thread D is a low priority thread, when thread C requests a lock, the scheduler checks the lock status. If the lock is occupied, the scheduler will insert thread C into the first waiting queue according to its priority to ensure that high priority threads are scheduled first. Once the lock becomes free, the scheduler will wake up the thread with the highest priority in the queue, allowing it to acquire the mutex lock and continue to execute the corresponding task. The low priority thread D will move to the back of the queue.
[0068] Through this embodiment, by flexibly configuring the queue scheduling attributes, the lock acquisition strategy can be adjusted for different application scenarios. Specifically: when the queue scheduling attribute is first-in first-out, it is guaranteed that all threads acquire the mutual exclusion lock fairly in the order of requesting the lock. When the queue scheduling attribute is arranged according to thread priority, high-priority threads can obtain priority when requesting and acquiring locks, reducing the waiting time and response time of key tasks and improving the response speed of real-time systems.
[0069] In an exemplary embodiment, after adding the first thread to the first waiting queue associated with the mutex, the method further includes:
[0070] When the lock attribute of the mutex lock configuration includes a priority inheritance attribute and the priority of the first thread is higher than the priority of the third thread, the priority of the third thread is increased to the second priority, wherein the third thread is the thread currently owning the mutex lock.
[0071] It should be noted that the priority inheritance attribute is used to increase the priority of the thread that currently owns the mutex lock. When the working state of the mutex lock is the locked state, and the lock attribute configured by the mutex lock does not include the recursive attribute but includes the priority inheritance attribute, the second priority can be determined according to the priorities of all threads currently existing in the operating system. The second priority can be greater than or equal to the maximum value of the priorities of all currently existing threads, or can be the maximum value of the pre-set priorities.
[0072] In practice, in an embedded real-time operating system, there are three threads: thread T1 (high priority) and thread T2 (low priority). Thread T2 currently holds a mutex and is executing its task. At this time, thread T1 attempts to acquire the same mutex in order to execute its critical section code. Since the working state of the mutex is locked and the priority of T1 is higher than that of T2, thread T1 needs to be added to the tail of the first waiting queue and the priority of thread T2 needs to be raised to the second priority.
[0073] Through this embodiment, when the working state of the mutex lock is the locked state, and the lock attribute configured by the mutex lock does not include a recursive attribute but includes a priority inheritance attribute, by improving the priority of the thread that owns the mutex lock, it can be ensured that when a low-priority thread holds the lock, its priority is improved to avoid being preempted by a lower-priority thread, thereby solving the priority inversion problem.
[0074] In an exemplary embodiment, after raising the priority of the third thread to the second priority, the method further includes:
[0075] When the third thread releases the mutex, the priority of the third thread is restored from the second priority to the priority before being increased.
[0076] Exemplarily, the third thread releases the mutex, that is, the task execution in the third thread is completed, and the working state of the corresponding mutex is unlocked. After detecting that the third thread releases the mutex, the priority of the third thread is restored from the second priority to the priority before the increase.
[0077] In practice, a thread may hold more than one mutex. When a mutex with priority inheritance is released, check whether the thread that releases the lock (assuming it is thread T) currently holds other mutexes with priority inheritance or priority protection attributes, and the priority increase of thread T by these mutexes. By traversing all mutexes with priority inheritance held by thread T, find the thread priority increase records recorded due to these locks, and restore the priority of thread T to the priority before it was raised, that is, the highest value of the original priority of thread T or the priority increased due to other mutexes with priority inheritance or priority protection attributes.
[0078] Through this embodiment, after the priority of the third thread is raised to the second priority, when the third thread releases the mutex lock, the priority of the third thread is restored to ensure that the priority management is temporary and maintain the fairness of the embedded operating system scheduling.
[0079] To better understand the task processing process based on mutex locks, an example is used to illustrate. Figure 3 , shows an optional flowchart of acquiring a mutex lock in an embodiment of the present application, and reference Figure 4 , shows an optional flow chart of releasing a mutex lock in an embodiment of the present application. The process includes the following steps:
[0080] Step S301, the first thread is waiting to access a shared resource;
[0081] Step S302, determining whether the working state of the mutex lock is unlocked;
[0082] When the working state of the mutex lock is unlocked, jump to step S303; when the working state of the mutex lock is not unlocked, jump to step S305.
[0083] Step S303, acquiring a mutex lock;
[0084] Step S304, when the lock attribute of the mutex lock configuration includes a priority protection attribute, raising the priority of the first thread to a first priority, and executing the first task according to the first priority;
[0085] Step S305, determining whether the lock attribute of the mutex lock configuration includes a recursive attribute;
[0086] When the lock attribute of the mutex lock configuration does not include a recursive attribute, jump to step S309; when the lock attribute of the mutex lock configuration includes a recursive attribute, jump to step S306.
[0087] Step S306, determining whether the first thread and the second thread are the same thread;
[0088] Specifically, when the first thread and the second thread are not the same thread, jump to step S307; when the first thread and the second thread are the same thread, jump to step S308.
[0089] Step S307, adding the first thread to the first waiting queue associated with the mutex lock;
[0090] Step S308, adding the first task to the second waiting queue;
[0091] Step S309, determining whether the lock attribute of the mutex lock configuration includes a priority inheritance attribute;
[0092] Specifically, when the lock attribute of the mutex lock configuration includes the priority inheritance attribute, jump to step S310 ; when the lock attribute of the mutex lock configuration does not include the priority inheritance attribute, jump to step 309 .
[0093] Step S310, raising the priority of the third thread to the second priority, and adding the first thread to the first waiting queue associated with the mutex lock.
[0094] In another example, reference Figure 4 , shows a flowchart of releasing a mutex lock according to an embodiment of the present application, including the following steps:
[0095] Step S401, determine whether the mutex lock is released;
[0096] In specific practice, whether the mutex is released can be determined based on whether the lock_out of the mutex is 0.
[0097] If the mutex lock is released, jump to step S402; if the mutex lock is not released, continue to determine whether the mutex lock is released.
[0098] Step S402, restoring the thread priority to the priority before the increase;
[0099] Specifically, when the first thread releases the mutex, the priority of the first thread is restored from the first priority to the priority before the increase. When the third thread releases the mutex, the priority of the third thread is restored from the second priority to the priority before the increase.
[0100] Step S403, determining whether there is a thread in the first waiting queue;
[0101] Specifically, when there is a thread in the first waiting queue, jump to step S404; when there is no thread in the first waiting queue, jump to step S405.
[0102] Step S404: assigning the mutex lock to the head thread in the first waiting queue.
[0103] Step S405, triggering scheduling.
[0104] Triggering scheduling specifically includes waiting for a new thread to access a shared resource, or executing a task of a head thread in a first waiting queue.
[0105] In the above embodiment, by introducing flexible lock attribute configurations in the process of acquiring and releasing mutex locks, such as recursive attributes, priority protection attributes, priority inheritance attributes, and setting queue scheduling attributes for the first waiting queue, the system can flexibly respond to various real-time and priority requirements through different lock attributes and queue scheduling strategies, thereby improving the system's scenario adaptability. Recursive attribute support avoids deadlocks in recursive calls, priority protection attributes avoid unnecessary context switching, and priority inheritance attributes solve the priority flipping problem, thereby improving the stability and reliability of the system.
[0106] It should be noted that, for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that the present application is not limited by the described order of actions, because according to the present application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by the present application.
[0107] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, can be embodied in the form of a software product, which is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk), and includes a number of instructions for a terminal device (which can be a mobile phone, computer, server, or network device, etc.) to execute the methods described in each embodiment of the present application.
[0108] According to another aspect of the embodiment of the present application, an optional task processing device based on a mutex lock is also provided, and the device is used to implement the task processing method based on a mutex lock provided in the above-mentioned embodiment, which has been described and will not be repeated. As used below, the term "module" can implement a combination of software and / or hardware of a predetermined function. Although the device described in the following embodiments is preferably implemented in software, the implementation of hardware, or a combination of software and hardware is also possible and conceived.
[0109] Figure 5 is a structural block diagram of an optional task processing device based on a mutex lock according to an embodiment of the present application, which is applied to an embedded operating system. The embedded operating system is configured with a mutex lock corresponding to a shared resource. The mutex lock allows configuration of at least one lock attribute, such as Figure 5 As shown, the device may include:
[0110] An acquisition module 502 is used to acquire the working state of the mutex lock when a first thread is about to access a shared resource; the first thread is a thread of a first task to be executed in the embedded operating system;
[0111] A first priority-raising module 504 is configured to, when the working state of the mutex lock is unlocked, the lock attribute configured by the mutex lock includes a priority protection attribute, and the priority of the first thread is lower than the first priority, assign the mutex lock to the first thread, raise the priority of the first thread to the first priority, and execute the first task according to the first priority;
[0112] A queue adding module 506, configured to add the first thread to a first waiting queue of the mutex lock when the working state of the mutex lock is a locked state and the lock attribute configured by the mutex lock does not include a recursive attribute;
[0113] The first execution module 508 is configured to allocate the mutex lock to the first thread according to the order of the first thread in the first waiting queue, and execute the first task according to the priority of the first thread.
[0114] In an exemplary embodiment, the mutex-based task processing device further includes: a first recovery module;
[0115] The first recovery module is used to restore the priority of the first thread from the first priority to the priority before the increase when the first thread releases the mutex lock.
[0116] In an exemplary embodiment, the task processing device based on a mutex lock further includes: a judgment module and a joining module;
[0117] A judgment module, used for judging whether the first thread and the second thread are the same thread when the working state of the mutex lock is a locked state and the lock attribute configured by the mutex lock includes a recursive attribute, wherein the second thread is a thread that owns the mutex lock;
[0118] A joining module is used to add the first task to the second waiting queue when the first thread and the second thread are the same thread, wherein the second waiting queue is a waiting queue for a mutex lock that is in a locked state and whose attribute information includes recursive attribution, and the second waiting queue is used to record different tasks of the thread that owns the mutex lock.
[0119] In an exemplary embodiment, the task processing device based on a mutex lock further includes: a second execution module and a third execution module;
[0120] A second execution module, used for executing each task in the second waiting queue in sequence according to the order of the tasks in the second waiting queue until the second waiting queue is empty;
[0121] The third execution module is used to allocate the mutex lock to the head thread in the first waiting queue, and execute the task corresponding to the head thread according to the priority of the head thread.
[0122] In an exemplary embodiment, the queue adding module 506 includes: a queue adding unit;
[0123] The queue adding unit is used to add the first thread to the first waiting queue according to the queue scheduling attribute of the first waiting queue, wherein the queue scheduling attribute is used to indicate the order in which the threads in the first waiting queue acquire the mutex lock.
[0124] In an exemplary embodiment, a queue adding unit is used to add a first thread to the end of a first waiting queue when the queue scheduling attribute is first-in-first-out; and to add the first thread to the first waiting queue based on the priority of the first thread when the queue scheduling attribute is arranged according to thread priority, wherein each thread in the first waiting queue is sorted in sequence according to the priority of the corresponding thread.
[0125] In an exemplary embodiment, after the first thread is added to the first waiting queue of the mutex lock, the task processing device based on the mutex lock further includes: a second priority increase module, which is used to increase the priority of the third thread to the second priority when the lock attribute of the mutex lock configuration includes a priority inheritance attribute and the priority of the first thread is higher than the priority of the third thread, wherein the third thread is the thread that currently owns the mutex lock.
[0126] In an exemplary embodiment, after the priority of the third thread is raised to the second priority, the mutex-based task processing device further includes: a second recovery module;
[0127] The second recovery module is used to restore the priority of the third thread from the second priority to the priority before the increase when the third thread releases the mutex lock.
[0128] It should be noted that the above modules can be implemented by software or hardware. For the latter, it can be implemented in the following ways, but not limited to: the above modules are all located in the same processor; or the above modules are located in different processors in any combination.
[0129] According to another aspect of the embodiments of the present application, a computer-readable storage medium is provided. The computer-readable storage medium includes a stored program, wherein the program executes the steps of any of the above method embodiments when it is run.
[0130] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, a ROM, a RAM, a mobile hard disk, a magnetic disk, or an optical disk.
[0131] According to another aspect of the embodiments of the present application, an electronic device is also provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor is configured to execute the steps in any of the above method embodiments through the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.
[0132] For specific examples in this embodiment, reference may be made to the examples described in the above embodiments and exemplary implementation modes, and this embodiment will not be described in detail herein.
[0133] According to another aspect of the embodiment of the present application, a computer program product is also provided, which includes a computer program / instruction, and the computer program / instruction contains a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit 601, various functions provided by the embodiment of the present application are executed. The above-mentioned serial numbers of the embodiments of the present application are only for description and do not represent the advantages and disadvantages of the embodiments.
[0134] Figure 6 The computer system structure block diagram of the electronic device used to implement the embodiment of the present application is schematically shown. Figure 6 As shown, the computer system 600 includes a CPU (Central Processing Unit) 601, which can perform various appropriate actions and processes according to the program stored in the ROM 602 or the program loaded from the storage part 608 to the RAM 603. Various programs and data required for system operation are also stored in the random access memory 603. The central processing unit 601, the read-only memory 602 and the random access memory 603 are connected to each other through a bus 604. An I / O (Input / Output) interface 605 is also connected to the bus 604.
[0135] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a CRT (Cathode Ray Tube), an LCD (Liquid Crystal Display), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the input / output interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed so that a computer program read therefrom is installed into the storage section 608 as needed.
[0136] In particular, according to an embodiment of the present application, the process described in each method flow chart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a computer readable medium, and the computer program contains a program code for executing the method shown in the flow chart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processor 601, various functions defined in the system of the present application are executed.
[0137] It should be noted that Figure 6 The computer system 600 of the electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.
[0138] Obviously, those skilled in the art should understand that the above modules or steps of the present application can be implemented by a general computing device, they can be concentrated on a single computing device, or distributed on a network composed of multiple computing devices, they can be implemented by a program code executable by a computing device, so that they can be stored in a storage device and executed by the computing device, and in some cases, the steps shown or described can be executed in a different order from that herein, or they can be made into individual integrated circuit modules, or multiple modules or steps therein can be made into a single integrated circuit module for implementation. Thus, the present application is not limited to any specific combination of hardware and software.
[0139] The above are only preferred embodiments of the present application and are not intended to limit the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the principles of the present application shall be included in the protection scope of the present application.
Claims
1. A task processing method based on a mutex lock, characterized in that: Applied to an embedded operating system, the embedded operating system is configured with a mutex lock corresponding to a shared resource, the mutex lock allows configuration of at least one lock attribute, the method comprises: When a first thread is about to access the shared resource, obtaining the working state of the mutex lock; the first thread is a thread of a first task to be executed in the embedded operating system; When the working state of the mutex lock is unlocked, the lock attribute configured by the mutex lock includes a priority protection attribute, and the priority of the first thread is lower than a first priority, the mutex lock is assigned to the first thread, the priority of the first thread is increased to the first priority, and the first task is executed according to the first priority; When the working state of the mutex lock is a locked state and the lock attribute configured by the mutex lock does not include a recursive attribute, adding the first thread to a first waiting queue associated with the mutex lock; The mutex lock is allocated to the first thread according to the order of the first thread in the first waiting queue, and the first task is executed according to the priority of the first thread.
2. The method according to claim 1, characterized in that After raising the priority of the first thread to the first priority, the method further includes: When the first thread releases the mutex lock, the priority of the first thread is restored from the first priority to the priority before being increased.
3. The method according to claim 1, characterized in that The method further comprises: When the working state of the mutex lock is a locked state and the lock attribute configured by the mutex lock includes a recursive attribute, determining whether the first thread and the second thread are the same thread, wherein the second thread is a thread that owns the mutex lock; When the first thread and the second thread are the same thread, the first task is added to a second waiting queue, wherein the second waiting queue is a waiting queue for a mutex lock that is in a locked state and whose attribute information includes a recursive mutex lock, and the second waiting queue is used to record different tasks of the thread that owns the mutex lock.
4. The method according to claim 3, characterized in that After adding the first task to the second waiting queue, the method further includes: Execute each task in the second waiting queue in sequence according to the order of the tasks in the second waiting queue until the second waiting queue is empty; The mutex lock is allocated to the head thread in the first waiting queue, and the task corresponding to the head thread is executed according to the priority of the head thread.
5. The method according to claim 1, characterized in that The step of adding the first thread to a first waiting queue associated with the mutex lock comprises: The first thread is added to the first waiting queue according to a queue scheduling attribute of the first waiting queue, wherein the queue scheduling attribute is used to indicate an order in which threads in the first waiting queue acquire the mutex lock.
6. The method according to claim 5, characterized in that The adding the first thread to the first waiting queue according to the queue scheduling attribute of the first waiting queue comprises: When the queue scheduling attribute is first-in-first-out, adding the first thread to the tail of the first waiting queue; When the queue scheduling attribute is arranged according to thread priority, the first thread is added to the first waiting queue based on the priority of the first thread, wherein each thread in the first waiting queue is sorted in sequence according to the priority of the corresponding thread.
7. The method according to any one of claims 1 to 6, characterized in that After adding the first thread to a first waiting queue associated with the mutex lock, the method further comprises: When the lock attribute of the mutex lock configuration includes a priority inheritance attribute and the priority of the first thread is higher than the priority of a third thread, the priority of the third thread is increased to a second priority, wherein the third thread is the thread currently owning the mutex lock.
8. The method according to claim 7, characterized in that After raising the priority of the third thread to the second priority, the method further includes: When the third thread releases the mutex lock, the priority of the third thread is restored from the second priority to the priority before being increased.
9. A task processing device based on a mutex lock, characterized in that: Applied to an embedded operating system, the embedded operating system is configured with a mutex lock corresponding to a shared resource, the mutex lock allows configuration of at least one lock attribute, the device comprises: An acquisition module, used for acquiring the working state of the mutex lock when a first thread is about to access the shared resource; the first thread is a thread of a first task to be executed in the embedded operating system; A first priority-raising module is configured to assign the mutex lock to the first thread, raise the priority of the first thread to the first priority, and execute the first task according to the first priority when the working state of the mutex lock is unlocked, the lock attribute configured by the mutex lock includes a priority protection attribute, and the priority of the first thread is lower than the first priority; A queue adding module, configured to add the first thread to a first waiting queue associated with the mutex lock when the working state of the mutex lock is a locked state and the lock attribute configured by the mutex lock does not include a recursive attribute; The first execution module is used to allocate the mutex lock to the first thread according to the order of the first threads in the first waiting queue, and execute the first task according to the priority of the first thread.
10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, wherein the computer program implements the method according to any one of claims 1 to 8 when executed by a processor.