Method for managing multiple types of semaphores in a real-time operating system

Abstract

The application relates to the technical field of semaphore management, in particular to a management method of multiple types of semaphores in a real-time operating system. The method comprises the following steps: establishing a unified semaphore control structure to uniformly and abstractly manage binary semaphores, counting semaphores, mutual exclusion semaphores and read-write semaphores, wherein the unified semaphore control structure comprises a semaphore type identifier, state information, configuration options and a waiting queue; receiving an acquisition operation request or a release operation request for a target semaphore, and generating a type index according to the semaphore type identifier of the target semaphore; and calling a matched processing function from a corresponding type processing distribution table according to the type index. Through the unified semaphore abstract structure, the type index distribution table and the unified waiting queue management mechanism, the application realizes efficient and compatible management of multiple types of semaphores and precise task synchronization, and improves the synchronization resource scheduling efficiency, the expansion capability and the real-time response performance of the real-time operating system.

Description

Technical Field

[0001] This invention relates to the field of semaphore management technology, and in particular to a method for managing multiple types of semaphores in a real-time operating system. Background Technology

[0002] In real-time operating systems, synchronization mechanisms such as semaphores, mutexes, and read-write locks are widely used for inter-task synchronization, mutual exclusion of resource access, and event notification. Existing technologies typically design independent control structures for binary semaphores, counting semaphores, mutex semaphores, and read-write semaphores, and implement task blocking, resource release, and task wake-up processing by maintaining resource states, waiting queues, and task scheduling logic.

[0003] However, existing semaphores of various types are typically managed independently, with different data structures, operation interfaces, and processing flows corresponding to different semaphore types. This results in a lack of a unified abstract management mechanism among various synchronization objects. When a system runs multiple synchronization resources simultaneously, it is necessary to maintain the state processing and task scheduling logic for different types of semaphores separately, which complicates the kernel synchronization management process and reduces the efficiency of collaborative management of multiple types of semaphores. Summary of the Invention

[0004] Therefore, it is necessary to provide a method for managing multiple types of semaphores in a real-time operating system to solve at least one of the above-mentioned technical problems.

[0005] To achieve the above objectives, a method for managing multiple types of semaphores in a real-time operating system is provided, the method comprising the following steps: Step S1: Establish a unified semaphore control structure to perform unified abstract management of binary semaphores, counting semaphores, mutex semaphores and read / write semaphores. The unified semaphore control structure includes semaphore type identifier, status information, configuration options and waiting queue. Step S2: Receive an acquisition operation request or a release operation request for the target semaphore, and generate a type index based on the semaphore type identifier of the target semaphore; Step S3: Call the matching processing function from the corresponding type processing dispatch table according to the type index, and perform an acquisition operation or a release operation on the target semaphore. The type processing dispatch table includes an acquisition processing dispatch table, a release processing dispatch table, and a refresh processing dispatch table. Step S4: When the resource status corresponding to the acquisition operation does not meet the task execution conditions, add the current task to the waiting queue, and wake up the waiting task according to the queue scheduling strategy when the resource status meets the conditions. Step S5: When the target semaphore is a mutex semaphore, mutual exclusion control is performed based on the occupant identifier and recursive count in the status information, and priority inheritance processing is performed based on the task priority status adjustment.

[0006] The present invention has the following beneficial effects: I. This invention establishes a unified semaphore control structure to uniformly abstract and manage binary semaphores, counting semaphores, mutex semaphores, and read / write semaphores. This enables different types of semaphores to have a consistent data organization method and access entry point, avoiding the code redundancy and maintenance complexity caused by designing separate management mechanisms for different semaphore types in existing real-time operating systems. This improves the management consistency of multi-type synchronization resources and the system's scalability.

[0007] Second, this invention constructs a processing distribution table based on type index, and dynamically matches the corresponding acquisition, release, and refresh processing functions according to the type identifier of the target semaphore. This decouples the semaphore operation process from the specific type processing logic, so that when adding a new semaphore type, there is no need to modify the core scheduling process. Only the corresponding processing function needs to be extended to complete the adaptation. This reduces the coupling degree of the real-time operating system kernel synchronization mechanism and improves the efficiency of semaphore operation and system compatibility.

[0008] Third, this invention sets up a unified waiting queue and establishes the association between task waiting nodes and semaphore state change events based on synchronization constraint types. This enables blocked tasks corresponding to different types of semaphores to be managed and woken up in a unified manner. At the same time, combined with queue scheduling strategies and state matching mechanisms, it achieves accurate recovery of waiting tasks, reduces the resource occupation and scheduling overhead caused by traditional multi-waiting queue structures, and improves the synchronization control capability and response efficiency of the real-time operating system in a multi-task concurrent environment. Attached Figure Description

[0009] Figure 1 This is a flowchart illustrating the steps involved in a method for managing multiple types of semaphores in a real-time operating system. Figure 2 for Figure 1 A detailed flowchart illustrating the implementation steps of step S3. Figure 3 This is a schematic diagram of a semaphore architecture according to one embodiment; The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0010] The technical method of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0011] Furthermore, the accompanying drawings are merely illustrative of the invention and are not necessarily drawn to scale. The same reference numerals in the drawings denote the same or similar parts, and therefore repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor methods and / or microcontroller methods.

[0012] It should be understood that although the terms "first," "second," etc., may be used herein to describe various units, these units should not be limited by these terms. These terms are used merely to distinguish one unit from another. For example, without departing from the scope of the exemplary embodiments, a first unit may be referred to as a second unit, and similarly, a second unit may be referred to as a first unit. The term "and / or" as used herein includes any and all combinations of one or more of the associated listed items.

[0013] To achieve the above objectives, please refer to Figures 1 to 3 A method for managing multiple types of semaphores in a real-time operating system, the method comprising the following steps: Step S1: Establish a unified semaphore control structure to perform unified abstract management of binary semaphores, counting semaphores, mutex semaphores and read / write semaphores. The unified semaphore control structure includes semaphore type identifier, status information, configuration options and waiting queue. Step S2: Receive an acquisition operation request or a release operation request for the target semaphore, and generate a type index based on the semaphore type identifier of the target semaphore; Step S3: Call the matching processing function from the corresponding type processing dispatch table according to the type index, and perform an acquisition operation or a release operation on the target semaphore. The type processing dispatch table includes an acquisition processing dispatch table, a release processing dispatch table, and a refresh processing dispatch table. Step S4: When the resource status corresponding to the acquisition operation does not meet the task execution conditions, add the current task to the waiting queue, and wake up the waiting task according to the queue scheduling strategy when the resource status meets the conditions. Step S5: When the target semaphore is a mutex semaphore, mutual exclusion control is performed based on the occupant identifier and recursive count in the status information, and priority inheritance processing is performed based on the task priority status adjustment.

[0014] In some embodiments, taking the semaphore management process in a real-time operating system as an example, the real-time operating system needs to support multiple synchronization mechanisms such as binary semaphores, counting semaphores, mutex semaphores, and read / write semaphores to meet the resource access, event notification, and synchronization control requirements between different tasks.

[0015] During system operation, multiple tasks may simultaneously request the operating system to acquire or release different types of semaphores. For example, task A needs to access shared resources through a mutex semaphore, task B needs to acquire a limited number of system resources through a counting semaphore, task C needs to wait for event notifications through a binary semaphore, and task D needs to perform shared data read operations through a read-write semaphore. Since different types of semaphores have different state management methods and synchronization rules, the system first establishes a unified semaphore control structure to perform unified abstract management of different types of semaphores.

[0016] Specifically, the system creates a unified semaphore control structure for each semaphore object, which includes a semaphore type identifier, status information, configuration options, and a waiting queue.

[0017] The semaphore type identifier records the type of the current semaphore. For example, a binary semaphore corresponds to the event notification type, a counting semaphore corresponds to the resource quantity control type, a mutex semaphore corresponds to the exclusive access type, and a read-write semaphore corresponds to the read-write permission control type. The status information records the current running status of different types of semaphores. For example, a counting semaphore records the current count value, a mutex semaphore records the current occupant identifier and recursive counting, and a read-write semaphore records the current read status and write status. The configuration options record the semaphore running parameters. The waiting queue stores tasks that have entered a blocked state because the resource status does not meet the execution conditions.

[0018] For example, when the system creates a mutex semaphore, the mutex semaphore type identifier is written into the unified semaphore control structure, and the current occupancy status is recorded in the status information; when the system creates a counting semaphore, the current resource count value is recorded in the corresponding status information. Different types of semaphores are described using the same control structure.

[0019] Furthermore, when the system receives an acquisition or release request for the target semaphore, it generates a type index based on the semaphore type identifier of the target semaphore.

[0020] Specifically, the system reads the type identifier field from the target semaphore control structure and determines the type of the current semaphore based on the type identifier field. Subsequently, the system performs logical operations on the type identifier and the type mask to extract the valid type bits representing the semaphore type, and converts the valid type bits to obtain the corresponding type index.

[0021] For example, when a task requests to acquire a mutex semaphore, the system reads the type identifier field in the target semaphore and obtains the type index corresponding to the mutex semaphore after logical processing; when a task requests to release a counting semaphore, the system generates the type index corresponding to the counting semaphore based on the counting semaphore type identifier.

[0022] Furthermore, based on the generated type index, the system calls the matching processing function from the corresponding type processing dispatch table and performs an acquisition or release operation on the target semaphore.

[0023] Specifically, the system selects the corresponding processing dispatch table based on the current operation request type. Specifically, when a get operation request is received, the get processing dispatch table is accessed; when a release operation request is received, the release processing dispatch table is accessed; and when it is necessary to update the status of waiting tasks, the refresh processing dispatch table is accessed.

[0024] For example, when a task requests to acquire a mutex semaphore, the system locates the corresponding processing function in the acquisition processing dispatch table based on the type index of the mutex semaphore, and calls the processing function to read the current state information of the mutex semaphore.

[0025] If the mutex semaphore is not currently occupied by other tasks, the processing function updates the status information and associates the current task with the semaphore; if the mutex semaphore is already occupied, it is determined that the current task cannot immediately acquire the resource and enters the waiting process.

[0026] For example, when a task releases a counting semaphore, the system calls the corresponding release processing function in the release processing dispatch table according to the counting semaphore type index, updates the counting status, and executes the waiting task refresh processing according to the updated resource status.

[0027] Furthermore, when the resource status corresponding to the acquisition operation does not meet the task execution conditions, the system adds the current task to the waiting queue, and wakes up the waiting task according to the queue scheduling strategy when the resource status meets the conditions.

[0028] Specifically, when a task requests to acquire a target semaphore, the system first determines whether the current state of the target semaphore meets the acquisition conditions.

[0029] For example, for a counting semaphore, the system determines whether the current count value is greater than zero; for a mutex semaphore, the system determines whether there is another task currently occupying the memory; for a binary semaphore, the system determines whether the current event state is valid; and for a read / write semaphore, the system determines whether the current read / write state meets the access conditions.

[0030] When the current resource status is detected as not meeting the task execution conditions, the system extracts the current task control information, creates a corresponding waiting node, and writes the task identifier, target semaphore identifier, and waiting status information into the waiting node.

[0031] Subsequently, the system adds the waiting nodes to a unified waiting queue and determines the arrangement of waiting tasks according to the configured queue scheduling strategy.

[0032] For example, when using a first-in-first-out (FIFO) queue strategy, the system arranges waiting nodes according to the order in which tasks enter the waiting queue; when using a priority queue strategy, the system adjusts the position of waiting nodes according to task priority, so that high-priority tasks can resume execution first.

[0033] When the state of the target semaphore changes and the corresponding synchronization constraint condition is met, the system locates the task to be recovered based on the association between the waiting node and the target semaphore, and switches the corresponding task from the waiting state to the executable state.

[0034] Furthermore, when the target semaphore is a mutex semaphore, the system performs mutual exclusion control based on the occupant identifier and recursive count in the status information, and adjusts the execution priority inheritance process based on the task priority status.

[0035] Specifically, the system reads the occupant identifier from the mutex semaphore status information to determine the task currently holding the mutex semaphore, and at the same time reads the recursive count to determine the number of times the current task has repeatedly acquired the mutex semaphore.

[0036] For example, when the same task requests to acquire a mutex semaphore that it already holds, the system performs recursive acquisition based on the recursive count, without having to recreate the resource contention relationship; when other tasks request to acquire the mutex semaphore, the system determines whether the current resource is available for transfer based on the occupant identifier.

[0037] When a high-priority task is waiting for a low-priority task to release a mutex semaphore, the system checks the current task priority status and performs priority inheritance processing, adjusting the execution priority of the occupying task to the corresponding level, so that the occupying task can restore its original priority after releasing the resources.

[0038] As an example of the present invention, reference is made to Figure 2 As shown, step S3 in this example includes: Step S31: Obtain the type index corresponding to the target semaphore, wherein the type index is obtained by performing logical operations on the type identifier and type mask in the target semaphore control structure; Step S32: Determine the corresponding type processing table based on the currently received operation request type, wherein the type processing table includes releasing the operation table, obtaining the operation table, and refreshing the operation table; Step S33: Based on the type index, read the address of the target processing function from the corresponding type processing dispatch table, and call the target processing function to perform corresponding operation synchronization processing on the target semaphore.

[0039] In some embodiments, the semaphore operation process in a real-time operating system is still taken as an example.

[0040] During system operation, task A sends a semaphore acquisition request to the system, requesting to acquire a specific target semaphore. Upon receiving this request, the system executes a semaphore processing procedure based on type index.

[0041] Specifically, the system first obtains the type index corresponding to the target semaphore, where the type index is obtained by logical operation between the type identifier and the type mask in the target semaphore control structure.

[0042] For example, the system reads the type identifier field from the target semaphore control structure. This field indicates the type of the current target semaphore. If the current target semaphore is a mutex semaphore, the type identifier field records the corresponding mutex type code; if the current target semaphore is a counting semaphore, the type identifier field records the corresponding counting type code.

[0043] Subsequently, the system reads the pre-configured type mask and performs a logical AND operation between the type identifier field and the type mask to extract the valid type bits in the type identifier field.

[0044] For example, the type identifier field in the target semaphore control structure is a combined field containing type information and control flags. The system filters out non-type information through a type mask, retains only the valid type bit used to distinguish between binary semaphores, counting semaphores, mutex semaphores, and read / write semaphores, and converts the valid type bit into the corresponding type index.

[0045] Furthermore, the system determines the corresponding type processing table based on the type of operation request currently received, whereby the type processing table includes releasing the operation table, acquiring the operation table, and refreshing the operation table.

[0046] Specifically, when the system receives a semaphore acquisition request from a task, it selects the acquisition operation dispatch table according to the current operation request type; when it receives a semaphore release request from a task, it selects the release operation dispatch table; when the system needs to update the waiting task status or refresh the semaphore status, it selects the refresh operation dispatch table.

[0047] For example, when a task requests to acquire a mutex semaphore, the system determines that the current request type is an acquire operation, and therefore selects the acquire operation dispatch table; when the task completes resource access and releases the mutex semaphore, the system determines that the current request type is a release operation, and therefore switches to the release operation dispatch table.

[0048] Furthermore, the system reads the address of the target processing function from the corresponding type processing dispatch table based on the type index, and calls the target processing function to perform corresponding operation synchronization processing on the target semaphore.

[0049] For example, when a task requests to acquire a mutex semaphore, the system locates the corresponding function address in the acquisition operation dispatch table based on the previously generated mutex semaphore type index, and reads the mutex semaphore acquisition processing function corresponding to that type index.

[0050] Subsequently, the system calls the processing function to determine the current state of the target mutex semaphore. When it is detected that the mutex semaphore is not currently occupied by other tasks, the processing function updates the target semaphore state information, records the current task as the occupant, and completes the acquisition operation; when it is detected that the mutex semaphore is already occupied by other tasks, the processing function adds the current task to the waiting queue according to the waiting queue management rules.

[0051] For example, when a task releases a counting semaphore, the system reads the address of the corresponding release processing function from the release operation dispatch table based on the counting semaphore type index, and calls the processing function to update the target counting semaphore state.

[0052] The processing function reads the current count value, increments the corresponding resource count according to the release operation, and further checks whether there are any tasks in the waiting queue that meet the resource acquisition conditions; if so, it selects the corresponding task to perform the wake-up process according to the queue scheduling policy.

[0053] For example, during the read / write semaphore status refresh process, the system reads the address of the corresponding refresh processing function from the refresh operation dispatch table based on the read / write semaphore type index, and calls the refresh processing function to update the current read / write status, including the current number of read tasks, the status of write tasks in use, and the status of waiting tasks.

[0054] Preferably, after calling the target processing function to perform corresponding operation synchronization processing on the target semaphore, the process further includes: Read the current state information in the target semaphore control structure, including the counting state or the occupied state, and determine the corresponding state update method according to the current operation type; When a request to acquire is received, the current resource status is assessed based on the target semaphore type: for counting semaphores, the remaining resource quantity is determined based on the current count value; for mutex semaphores, the resource occupancy status is determined based on the occupant identifier. When the current resource status meets the acquisition conditions, update the status information corresponding to the target semaphore and complete the synchronization association between the current task and the target semaphore; When the current resource status does not meet the acquisition conditions, the current task information is written to a unified waiting queue, and the task waiting order is recorded according to the scheduling method configured in the waiting queue. After the target semaphore is released, based on the updated resource status after the release operation, the corresponding task is selected from the unified waiting queue to perform the wake-up process and restore the execution status of the task.

[0055] In some embodiments, the semaphore synchronization process in a real-time operating system is used as an example.

[0056] During system operation, task A sends a request to the system to acquire the target semaphore. The system determines the corresponding processing function based on the aforementioned type index and calls the target processing function to perform the acquisition operation and synchronous processing of the target semaphore.

[0057] Specifically, the target processing function first reads the current state information in the target semaphore control structure and determines the corresponding state update method based on the current operation type.

[0058] For example, when the target semaphore is a counting semaphore, the system reads the counting status information in the control structure to obtain the current remaining quantity of resources; when the target semaphore is a mutex semaphore, the system reads the occupancy status information in the control structure, including the current occupant identifier and the mutex resource locking status; when the target semaphore is a binary semaphore, the system reads the current event validity status; when the target semaphore is a read / write semaphore, the system reads the current number of read tasks and the write task occupancy status.

[0059] Based on the type of operation request currently received, the system determines the corresponding status update method.

[0060] For example, when a request to acquire is received, the target processing function enters the resource acquisition judgment process; when a request to release is received, the target processing function updates the corresponding status information according to the release operation, and further triggers the waiting task processing process.

[0061] Furthermore, when a request to acquire is received, the system determines the acquisition conditions based on the type of the target semaphore and the current resource status.

[0062] For example, for a counting semaphore, the system reads the current count value and determines whether the current count value is greater than zero.

[0063] When a task requests to acquire a counting semaphore, if the current count value is 3, it means that there are three available resources. The system determines that the current resource status meets the acquisition conditions and allows the task to acquire the corresponding resource. If the current count value is 0, it means that there are no available resources. The system determines that the current resource status does not meet the acquisition conditions.

[0064] For mutex semaphores, the system determines the current resource occupancy status based on the occupant identifier.

[0065] For example, when task A requests to acquire a mutex semaphore, the system reads the occupant identifier from the mutex semaphore status information. If the current occupant identifier is empty, it means that the mutex resource is not occupied by other tasks, and the system allows task A to acquire the mutex semaphore and updates the occupant information; if the current occupant identifier corresponds to task B, it means that the resource is already occupied, and the system determines that task A cannot acquire the resource immediately.

[0066] Furthermore, when the current resource status meets the acquisition conditions, the system updates the status information corresponding to the target semaphore and completes the synchronization association between the current task and the target semaphore.

[0067] For example, when task A successfully acquires the mutex semaphore, the system updates the occupant identifier in the mutex semaphore control structure, records task A as the current resource-holding task, and updates the mutex status field.

[0068] For counting semaphores, after a task successfully acquires resources, the system decrements the current count by one and updates the remaining number of resources.

[0069] For binary semaphores, after the task successfully obtains the event notification, the system updates the signal status from valid to invalid.

[0070] At the same time, the system records the association between the current task and the target semaphore in the task control information, so that subsequent release operations can determine the corresponding resource occupancy status.

[0071] Furthermore, when the current resource status does not meet the acquisition conditions, the system writes the current task information into a unified waiting queue and records the task waiting order according to the scheduling method configured in the waiting queue.

[0072] For example, when task A requests to acquire a mutex semaphore that is already occupied by task B, the target processing function determines that the current resource is unavailable, then extracts the task identifier, waiting type, and target semaphore identifier corresponding to task A, and generates a waiting node.

[0073] Subsequently, the system added the waiting node to the unified waiting queue.

[0074] When the unified waiting queue adopts the first-in-first-out scheduling method, the system arranges the waiting nodes according to the time order in which the tasks entered the waiting queue; when the priority scheduling method is adopted, the system reads the task priority information and adjusts the position of the waiting nodes according to the priority.

[0075] For example, if task A has a higher priority than task C in the current waiting queue, the system will adjust the waiting node corresponding to task A to be before task C, so that task A can be resumed first when resources are released later.

[0076] Furthermore, after the target semaphore is released, the system selects the corresponding task from the unified waiting queue to perform wake-up processing based on the updated resource status after the release operation, and restores the execution status of the task.

[0077] For example, when task B completes resource access and releases the mutex semaphore, the system calls the release handler function to clear the occupant identifier in the mutex semaphore and update the current resource state.

[0078] Subsequently, the system reads the waiting nodes associated with the mutex semaphore in the unified waiting queue and determines the tasks that meet the mutual exclusion acquisition conditions based on the updated resource status.

[0079] If task A is in a waiting state and meets the acquisition conditions, the system locates the corresponding waiting node for task A in the waiting queue and switches task A from the blocked state to the executable state.

[0080] In the scenario of releasing a counting semaphore, when the count value increases due to the release of resources by a task, the system determines whether there are any tasks waiting for resources based on the updated count status, and selects the corresponding task for recovery according to the waiting queue scheduling strategy.

[0081] For example, if multiple tasks are waiting for the same counting semaphore resource, the system determines the wake-up order according to the first-in-first-out (FIFO) strategy or the priority strategy, and resumes the execution of tasks that meet the conditions in turn.

[0082] Preferably, the method for obtaining the type index includes: Read the type identifier field in the target semaphore control structure. The type identifier field is used to characterize the type of the target semaphore. The semaphore type includes at least binary semaphore, mutex semaphore, counting semaphore, and read / write semaphore. Perform a validity check on the type identifier field to determine whether the type identifier field is within the preset semaphore type range; Obtain the type mask corresponding to the type identifier field, and perform logical operations between the type identifier field and the type mask to extract the valid type bits in the type identifier field; The valid type bits are converted to the corresponding type index, and the type index is used as the index parameter for accessing the type processing table to determine the processing function corresponding to the target semaphore.

[0083] In some embodiments, the example continues to be a unified processing procedure for multiple types of semaphores in a real-time operating system.

[0084] During system operation, tasks send target semaphore operation requests to the operating system. For example, task A requests to acquire a mutex semaphore, and task B requests to release a counting semaphore. After receiving the operation request, the system first generates a corresponding type index based on the type identifier in the target semaphore control structure.

[0085] Specifically, the system reads the type identifier field from the target semaphore control structure, where the type identifier field is used to characterize the type to which the target semaphore belongs.

[0086] For example, the system creates a unified control structure for each semaphore object, in which a type identifier field `sem_type` is set. When a binary semaphore is created, the system writes the corresponding type code of the binary semaphore into the type identifier field; when a mutex semaphore is created, the corresponding type code of the mutex semaphore is written; when a counting semaphore or a read / write semaphore is created, the corresponding type code is written respectively.

[0087] When task A requests to acquire the target semaphore, the system reads the type identifier field in the target semaphore control structure and determines the type of semaphore the current target semaphore belongs to based on the field content.

[0088] For example, after reading the target semaphore type identifier field, the system determines that the current type identifier corresponds to a mutex semaphore, and then determines that the corresponding processing function for the mutex semaphore needs to be called subsequently; if the current type identifier corresponds to a counting semaphore, then it determines that the corresponding processing function for the counting semaphore needs to be called subsequently.

[0089] Furthermore, the system performs a validity check on the type identifier field to determine whether the type identifier field is within the preset semaphore type range.

[0090] Specifically, after reading the type identifier field, the system compares the value of the field with the preset valid type range to determine whether the current type identifier belongs to the set of semaphore types supported by the system.

[0091] For example, the system predefines the supported semaphore types, including: binary semaphore type; mutex semaphore type; counting semaphore type; and read / write semaphore type.

[0092] When the type identifier field read corresponds to any of the above type codes, the system determines that the type identifier is valid; if the type identifier field read exceeds the above type range, the system determines that the current type identifier is invalid and does not execute the subsequent type index generation process.

[0093] Furthermore, after the type identifier field passes the validity check, the system obtains the type mask corresponding to the type identifier field, performs logical operations on the type identifier field and the type mask, and extracts the valid type bits in the type identifier field.

[0094] For example, the type identifier field in the system not only contains semaphore type information, but may also contain status flags or configuration flags. To prevent other control information from affecting type determination, the system sets a corresponding type mask.

[0095] After reading the target semaphore type identifier field, the system uses a type mask to perform a logical AND operation on the field, retaining only the valid type bits that indicate the semaphore type.

[0096] For example, the target semaphore type identifier field contains both type information and extended configuration identifier. The system filters the extended configuration part through a type mask and extracts only the valid type bits used to represent the mutex semaphore type, thereby obtaining accurate semaphore category information.

[0097] Furthermore, the system converts the valid type bits into the corresponding type index and uses the type index as the index parameter for accessing the type processing table to determine the processing function corresponding to the target semaphore.

[0098] Specifically, the system performs conversion based on the mapping relationship between valid type bits and preset type indexes to generate the corresponding type index.

[0099] For example, the system pre-establishes a type index mapping relationship: binary semaphores correspond to type index 0; mutex semaphores correspond to type index 1; counting semaphores correspond to type index 2; and read / write semaphores correspond to type index 3.

[0100] When the valid type bit extracted by the system corresponds to a mutex semaphore, it is converted into type index 1, and this type index is used as the index parameter for accessing, retrieving, releasing, or refreshing the processing distribution table.

[0101] Subsequently, the system accesses the corresponding type of processing dispatch table based on the current operation request type.

[0102] For example, when task A requests to acquire a mutex semaphore, the system accesses the acquisition processing table using index 1 of the mutex semaphore type and reads the mutex semaphore acquisition processing function corresponding to the index position; when task B releases a counting semaphore, the system accesses the release processing table using index 2 of the counting semaphore type and reads the corresponding release processing function.

[0103] Preferably, when the current resource status does not meet the acquisition conditions, the current task information is written to a unified waiting queue, and the task waiting order is recorded according to the scheduling method configured in the waiting queue, specifically including: Extract the task control information corresponding to the current task and associate the task control information with the waiting state of the target semaphore. The task control information includes at least the task identifier, waiting type and waiting time information. Based on the synchronization type corresponding to the target semaphore, the waiting requirements of the current task are mapped to the corresponding waiting nodes in a unified waiting queue, so that different types of semaphores can share the same waiting management entry point. Obtain the current queue organization state of the unified waiting queue, and determine the insertion position of the waiting node based on the queue strategy configured by the target semaphore. When a first-in-first-out queue is used, the waiting nodes are arranged according to the order in which the tasks enter; when a priority queue is used, the positions of the waiting nodes are adjusted according to the task priorities. After the waiting node is established, the current unavailable state of the target semaphore is written into the corresponding state field, and the association between the waiting node and the state change event of the target semaphore is established. When a change in the status of the target semaphore resource is detected, the corresponding waiting node is located according to the association relationship, and the task to be recovered is determined according to the organization status of the waiting queue.

[0104] In some embodiments, the example continues to be a unified wait management process for multiple types of semaphores in a real-time operating system.

[0105] During system operation, task A sends a request to the operating system to acquire a target semaphore. The system calls the corresponding acquisition processing function based on the target semaphore type, reads the current status information of the target semaphore, and determines whether the current resource meets the task's acquisition conditions.

[0106] For example, when task A requests to acquire a mutex semaphore, the system detects that the mutex semaphore has already been occupied by task B, and the current occupant is identified as task B. Therefore, the system determines that the current resource status does not meet the acquisition conditions of task A. When task A requests to acquire a counting semaphore, the system detects that the current count value is 0, indicating that there are no available resources. Similarly, the system determines that task A cannot acquire the semaphore immediately.

[0107] At this point, the system enters the waiting task management process.

[0108] Specifically, the system first extracts the task control information corresponding to the current task and associates the task control information with the waiting state of the target semaphore.

[0109] For example, when task A enters a blocked state while waiting for a mutex semaphore, the system reads the task identifier, current waiting type, and waiting time information from the task control block corresponding to task A, and generates a corresponding waiting record.

[0110] Among them, the task identifier is used to determine the specific task that needs to be restored when resources are released later; the waiting type is used to describe the type of resource that the current task is waiting for, such as mutual exclusion resource waiting, counted resource waiting, or event waiting; and the waiting time information is used to record the time point when the task enters the waiting state.

[0111] Subsequently, the system associates the aforementioned task control information with the current waiting state of the target semaphore and generates a corresponding waiting node.

[0112] For example, for task A waiting for a mutex semaphore, the system records the task A identifier, the target mutex semaphore identifier, and the waiting state for the release of the mutex resource in the waiting node; for task waiting for a counting semaphore, it records the task identifier, the counting semaphore identifier, and the waiting state for the resource quantity to meet the condition.

[0113] Furthermore, based on the synchronization type corresponding to the target semaphore, the system maps the waiting requirements of the current task to the corresponding waiting nodes in a unified waiting queue, so that different types of semaphores can share the same waiting management entry point.

[0114] Specifically, the system reads the type identifier in the target semaphore control structure to determine whether the current semaphore is a mutex semaphore, a counting semaphore, a binary semaphore, or a read / write semaphore, and generates a waiting node according to the corresponding synchronization type.

[0115] For example, when task A waits for a mutex semaphore, the system generates a mutex resource waiting node based on the mutex synchronization type and attaches it to the unified waiting queue; when task C waits for a counting semaphore, the system generates a counting resource waiting node based on the counting synchronization type and attaches it to the same unified waiting queue.

[0116] Since the waiting node records the task identifier, target semaphore identifier, and synchronization type information, waiting tasks corresponding to different types of semaphores can all be managed through a unified waiting queue.

[0117] Furthermore, the system obtains the current queue organization status of the unified waiting queue and determines the insertion position of the waiting node based on the queue strategy configured by the target semaphore.

[0118] For example, when the target mutex semaphore is configured using a first-in-first-out (FIFO) queue strategy, the system obtains the order of the existing waiting nodes in the current waiting queue and inserts the waiting node corresponding to task A into the tail of the queue according to the time order in which the tasks entered the waiting queue.

[0119] When the target semaphore is configured with a priority queue strategy, the system reads the priority information of task A and compares it with the priorities of other tasks in the current waiting queue.

[0120] For example, if task C already exists in the current waiting queue, and task A has a higher priority than task C, the system will adjust the insertion position of the waiting node so that the waiting node corresponding to task A is placed before task C, so that the higher priority task can be restored first when resources are released later.

[0121] Furthermore, after the waiting node is established, the system writes the current unavailable state of the target semaphore into the corresponding state field and establishes the association between the waiting node and the state change event of the target semaphore.

[0122] For example, when task A is waiting for a mutex semaphore, the system records the current resource unavailable state in the target mutex semaphore status information and associates the waiting node corresponding to task A with the "mutex semaphore release event".

[0123] When task B releases the mutex semaphore, the system can locate the corresponding waiting node based on the state change event.

[0124] For example, when a task is waiting for a counting semaphore, the system writes the current count value to the status field and establishes an association between the waiting node and the "count value increase event". When the subsequent count value meets the task requirements, the corresponding task processing is triggered.

[0125] Furthermore, when a change in the status of the target semaphore resource is detected, the system locates the corresponding waiting node based on the correlation and determines the task to be recovered according to the organization status of the waiting queue.

[0126] For example, when task B releases the mutex semaphore, the system detects that the target mutex semaphore has changed from an occupied state to an idle state, and locates the task node waiting for the mutex semaphore based on the release event correlation.

[0127] Subsequently, the system reads the task arrangement status in the unified waiting queue.

[0128] If the current system uses a first-in, first-out (FIFO) queue strategy, it selects the earliest task A that entered the waiting queue as the task to be recovered. If the current system uses a priority queue strategy, it compares the priorities of the waiting tasks and selects the task with the highest priority as the task to be recovered.

[0129] Once the task to be resumed is identified, the system updates the corresponding task status, switches the task from blocked to executable, and re-adds it to the operating system's task scheduling queue.

[0130] For example, after the mutex semaphore that task A was waiting for is released, the system removes the association between task A and the blocked state, allowing task A to rejoin the scheduling and execution and continue to perform subsequent resource access operations.

[0131] Preferably, based on the synchronization type corresponding to the target semaphore, the waiting requirements of the current task are mapped to the corresponding waiting nodes in a unified waiting queue, specifically including: Obtain the waiting requirement information corresponding to the current task, and determine the synchronization constraint type corresponding to the waiting requirement based on the type identifier of the target semaphore. The synchronization constraint type is used to characterize the resource release conditions that need to be met during the task waiting process. Based on the synchronization constraint type, the waiting node description information is generated, and the task identifier, target semaphore identifier and synchronization constraint type are written into the same waiting node, so that the waiting node has the ability to independently describe the waiting state of different semaphores. The waiting nodes are attached to a unified waiting queue, and a mapping relationship is established between the synchronization constraint type in the waiting nodes and the target semaphore state change event, so that the resource change event can be directly associated with the corresponding waiting task. During the operation of the unified waiting queue, the waiting tasks of different types of semaphores are identified according to the synchronization constraint type in the waiting nodes. When a target semaphore release event is detected, only the waiting nodes that meet the corresponding synchronization constraint conditions are given subsequent wake-up processing.

[0132] In some embodiments, the example continues to be a multi-type semaphore wait management process in a real-time operating system.

[0133] During system operation, task A requests to acquire the target mutex semaphore. Since the mutex semaphore is currently occupied by task B, the system determines that task A cannot acquire the resource immediately and enters the waiting task management process.

[0134] Specifically, the system first obtains the waiting requirement information corresponding to the current task, and then determines the synchronization constraint type corresponding to the waiting requirement based on the type identifier of the target semaphore.

[0135] For example, the system reads the type identifier field in the target mutex semaphore control structure to determine that the current target semaphore belongs to the mutex semaphore type. Based on the synchronization rules corresponding to the mutex semaphore, the system determines that the synchronization constraint type corresponding to the current task's waiting request is "resource occupancy status released".

[0136] Among them, the synchronization constraint type is used to characterize the resource release conditions that a task must meet when it resumes execution from a waiting state.

[0137] For example, when the target semaphore is a mutex semaphore, the synchronization constraint type is used to indicate that the waiting task needs to meet the condition that "the occupant identifier is cleared and the resource is in an idle state"; When the target semaphore is a counting semaphore, the synchronization constraint type is used to indicate that the waiting task needs to meet the condition that "the current count value reaches the required number of tasks"; When the target semaphore is a binary semaphore, the synchronization constraint type is used to indicate that the waiting task needs to satisfy the condition that "the event state becomes valid"; When the target semaphore is a read / write semaphore, the synchronization constraint type is used to indicate that the waiting task needs to meet the condition that "the read / write access status meets the corresponding permission requirements".

[0138] Furthermore, the system generates waiting node description information based on the determined synchronization constraint type, and writes the task identifier, target semaphore identifier, and synchronization constraint type into the same waiting node, so that the waiting node can independently describe the waiting state corresponding to different semaphores.

[0139] For example, for task A waiting for a mutex semaphore, the system creates a corresponding waiting node and writes the following into the waiting node: Task identifier: Used to indicate that the currently waiting task is task A; Target semaphore identifier: used to indicate that the currently waiting object is a target mutex semaphore; Synchronization constraint type: used to indicate that it is necessary to wait for the target mutex semaphore to change from an occupied state to an idle state.

[0140] If task C is waiting for a counting semaphore, the system creates another waiting node and writes the task C identifier, the corresponding counting semaphore identifier, and the synchronization constraint type "the count value meets the resource requirements".

[0141] In this way, waiting tasks for different types of semaphores are described using the same waiting node structure, without the need to establish a separate waiting management structure for each type of semaphore.

[0142] Furthermore, the system attaches waiting nodes to a unified waiting queue and establishes a mapping relationship between the synchronization constraint type in the waiting nodes and the target semaphore state change event, so that resource change events can be directly associated with the corresponding waiting tasks.

[0143] For example, after the waiting node corresponding to task A is added to the unified waiting queue, the system reads the target semaphore identifier in the waiting node and establishes the association between the waiting node and the target mutex semaphore release event.

[0144] When the target mutex semaphore is released, the system locates the waiting node associated with the mutex semaphore based on the state change event, without having to traverse all task states.

[0145] For example, for task C waiting for a counting semaphore, the system establishes a mapping relationship between waiting nodes and count value change events. When another task releases the counting semaphore, causing the current count value to increase, the system locates the corresponding waiting node based on this state change event.

[0146] Furthermore, during the operation of the unified waiting queue, the system identifies the status of waiting tasks of different types of semaphores according to the synchronization constraint type in the waiting node.

[0147] For example, the following waiting nodes may exist simultaneously in a unified waiting queue: Task A is waiting for the mutex semaphore to be released; Task C waits for the counter semaphore to increment; Task D is waiting for a binary semaphore event to be triggered.

[0148] When the system detects that a target mutex semaphore has been released, it first locates the associated waiting node based on the target semaphore identifier corresponding to the release event.

[0149] Subsequently, the system reads the synchronization constraint type in each waiting node and only determines the waiting node that meets the current mutex semaphore release condition.

[0150] For example, if the synchronization constraint type in the waiting node corresponding to task A is "occupier identifier released", and the current mutex semaphore state has changed from occupied state to idle state, then the system determines that task A meets the recovery conditions and enters the subsequent wake-up process.

[0151] The synchronization constraint type in the waiting node corresponding to task C is "count value meets resource requirements". Since the current change event is a mutex semaphore release event, which does not match the waiting condition of task C, the system keeps task C in the waiting state.

[0152] Furthermore, based on the waiting nodes that meet the synchronization constraints, the system switches the corresponding task status from the waiting state to the recoverable state, and re-adds it to the task scheduling process according to the task arrangement strategy in the unified waiting queue.

[0153] For example, when multiple tasks are waiting for the same mutex semaphore at the same time, the system determines the recovery task according to the order of the waiting nodes; if a first-in-first-out strategy is adopted, the task that entered the waiting queue earliest is selected; if a priority strategy is adopted, the corresponding waiting task is selected according to the task priority.

[0154] Preferably, determining the synchronization constraint type corresponding to the waiting requirement based on the type identifier of the target semaphore specifically involves: Read the type identifier in the target semaphore control structure and determine the synchronization type corresponding to the target semaphore based on the type identifier; Based on the synchronization type, the corresponding resource constraint information is extracted, and the resource occupancy status, counting status or read / write status corresponding to different semaphore types are converted into unified synchronization constraint parameters. A waiting requirement identifier is generated based on the synchronization constraint parameters, and the waiting requirement identifier is associated with the waiting node corresponding to the current task, so that the unified waiting queue can perform task matching based on the waiting requirement identifier.

[0155] In some embodiments, the example continues to be a multi-type semaphore wait task management process in a real-time operating system.

[0156] During system operation, task A requests to acquire a target semaphore. After the system calls the corresponding acquisition processing function, it detects that the current resource state does not meet the task execution conditions. For example, when task A requests to acquire a mutex semaphore, it detects that the mutex semaphore is already occupied by task B. Task A cannot immediately access the corresponding resource and therefore enters a waiting process.

[0157] Specifically, the system first reads the type identifier in the target semaphore control structure and determines the synchronization type corresponding to the target semaphore based on the type identifier.

[0158] For example, the system reads the type identifier field in the target mutex semaphore control structure to determine that the target semaphore belongs to the mutex semaphore type; if the type identifier read corresponds to a counting semaphore, then the current target semaphore belongs to the counting synchronization type; if the type identifier corresponds to a read / write semaphore, then the current target semaphore belongs to the read / write access control type.

[0159] The type identifier in the target semaphore control structure is used to distinguish the synchronization processing methods corresponding to different semaphore objects, enabling the system to determine the resource constraints during the current task waiting process based on the unified type field.

[0160] Furthermore, the system extracts the corresponding resource constraint information based on the determined synchronization type, and converts the resource occupancy status, counting status, or read / write status corresponding to different semaphore types into unified synchronization constraint parameters.

[0161] For example, when the target semaphore is a mutex semaphore, the system reads the resource occupancy status corresponding to the current mutex semaphore, including the current occupant identifier and the resource locking status, and converts "the occupant identifier is empty and the resource is in a released state" into the corresponding synchronization constraint parameters.

[0162] When the target semaphore is a counting semaphore, the system reads the current counting status, including the current count value and the amount of resources required by the task, and converts "the current count value meets the task acquisition requirements" into the corresponding synchronization constraint parameters.

[0163] When the target semaphore is a read / write semaphore, the system reads the current read / write status, including the current number of read tasks and the write task occupancy status, and converts "meets current access permission requirements" into the corresponding synchronization constraint parameters.

[0164] For example, when task A is waiting for a mutex semaphore, the system does not directly store the semaphore type information as "waiting for mutex semaphore," but instead converts it into a unified form of synchronization constraint parameters: Resource type: Mutually exclusive resource; Current status: Occupied; Recovery condition: The occupant's identifier is cleared.

[0165] Through the above transformation, the resource status corresponding to different types of semaphores can be described using a unified parameter form.

[0166] Furthermore, the system generates a waiting requirement identifier based on the synchronization constraint parameters and associates the waiting requirement identifier with the waiting node corresponding to the current task, so that the unified waiting queue can perform task matching based on the waiting requirement identifier.

[0167] Specifically, the system generates a corresponding waiting requirement identifier based on the synchronization constraint parameters and writes the waiting requirement identifier into the current task waiting node.

[0168] For example, for task A waiting for a mutex semaphore, the system generates a mutex resource release waiting flag based on the synchronization constraint parameter of "clearing the occupant flag" and writes it to the waiting node corresponding to task A.

[0169] For task C waiting for the counting semaphore, the system generates a counting resource satisfaction waiting flag based on the synchronization constraint parameter "the count value reaches a specified number" and writes it to the corresponding waiting node of task C.

[0170] For task D waiting for read / write semaphores, the system generates a read / write status satisfaction waiting flag based on the synchronization constraint parameter of "access permission satisfied" and writes it to the corresponding waiting node of task D.

[0171] Subsequently, the system adds the waiting nodes containing the waiting demand identifier to a unified waiting queue.

[0172] When a change in the state of a target semaphore is detected during the operation of the unified waiting queue, the system reads the corresponding semaphore identifier based on the resource change event and finds the associated waiting node.

[0173] For example, when task B releases the mutex semaphore, the system detects that the target mutex semaphore has changed from an occupied state to an idle state. Then, it reads the waiting requirement identifier associated with the mutex semaphore and searches for a waiting node in the unified waiting queue that meets the condition of "clearing the occupant identifier".

[0174] If the system detects that the waiting requirement identifier in the waiting node corresponding to task A matches the current resource change status, then the system determines that task A meets the recovery conditions and enters the task wake-up process.

[0175] As for task C waiting for the counting semaphore, since the current event is a mutex semaphore state change, its waiting requirement identifier does not match the current resource change event. Therefore, the system keeps task C in the waiting state.

[0176] Preferably, when no target semaphore release event is detected, the method further includes: Maintain the association between the current waiting node and the target semaphore, and read the synchronization constraint parameters corresponding to the waiting node; The current state of the target semaphore is periodically checked based on the synchronization constraint parameters to determine whether the current resource state meets the wake-up conditions corresponding to the waiting task. When the target semaphore state does not change to meet the conditions, update the waiting state information of the waiting node and keep the current task in a blocked state. When a change in the state of the target semaphore is detected but the synchronization constraint is not met, the waiting node maintains its position in the unified waiting queue and continues to perform state monitoring.

[0177] In some embodiments, the semaphore wait task monitoring process in a real-time operating system is still taken as an example.

[0178] During system operation, task A requests to acquire a target mutex semaphore. Since the mutex semaphore is currently occupied by task B, the system determines that task A cannot acquire the resource immediately according to the mutex semaphore acquisition process and adds the corresponding waiting node of task A to a unified waiting queue.

[0179] Specifically, the system first maintains the association between the current waiting node and the target semaphore, and then reads the synchronization constraint parameters corresponding to the waiting node.

[0180] For example, the waiting node corresponding to task A records the target mutex semaphore identifier and synchronization constraint parameters, where the synchronization constraint parameters are used to describe the resource conditions that task A needs to meet to resume execution.

[0181] For mutex semaphores, the synchronization constraint parameters in the waiting node include "occupier identifier released" and "resource status is idle"; for counting semaphores, the synchronization constraint parameters in the waiting node include "current count value reaches the task requirement"; for read-write semaphores, the synchronization constraint parameters in the waiting node include "current access status satisfies read-write permission requirements".

[0182] When the system detects that the target mutex semaphore has not been released, it retains the association between the waiting node corresponding to task A and the mutex semaphore, and reads the synchronization constraint parameters in the waiting node for subsequent resource status matching.

[0183] Furthermore, the system periodically verifies the current state of the target semaphore based on the synchronization constraint parameters to determine whether the current resource state meets the wake-up conditions corresponding to the waiting task.

[0184] Specifically, the system reads the status information in the target semaphore control structure according to the set detection cycle, and matches the current status information with the synchronization constraint parameters in the waiting node.

[0185] For example, for a mutex semaphore that task A is waiting for, the system reads the occupant identifier from the current mutex semaphore status information.

[0186] If the occupant identifier still corresponds to task B, it means that the current mutually exclusive resource is still in an occupied state, and the system determines that the current state does not meet the wake-up condition of task A.

[0187] For example, for task C waiting for a counting semaphore, the system reads the current count value. If the current count value is still less than the amount of resources required by task C, it is determined that the current counting state does not meet the corresponding synchronization constraint.

[0188] For task D waiting for read / write semaphores, the system reads the current read / write status. If there are still write tasks occupying resources, it is determined that the current access status does not meet the recovery conditions of task D.

[0189] Furthermore, when the state of the target semaphore does not change to meet the conditions, the system updates the waiting state information of the waiting node and keeps the current task in a blocked state.

[0190] For example, if the system periodically checks the status of the mutex semaphore that task A is waiting for and finds that the target mutex semaphore is still held by task B and the occupant identifier has not changed, then the system updates the waiting detection time, current waiting status, and resource monitoring status information in the waiting node of task A.

[0191] Meanwhile, the system keeps task A in a blocked state and does not add it to the task scheduling execution queue.

[0192] For example, if there are two tasks in a unified waiting queue, one waiting for a mutex semaphore and the other waiting for a counter semaphore, and the mutex semaphore is not released and the counter value is not increased, the system updates the status of the corresponding waiting nodes respectively and keeps tasks A and C waiting.

[0193] Furthermore, when a change in the state of the target semaphore is detected but the synchronization constraint is not met, the system maintains the position of the waiting node in the unified waiting queue and continues to perform state monitoring.

[0194] For example, when task A is waiting for a mutex semaphore, the system detects that task B releases the resource. However, because other high-priority tasks immediately acquire the mutex semaphore during the system scheduling process, the target mutex semaphore is put back into an occupied state. At this time, although the state of the target semaphore changes, the synchronization constraint condition of "resource is idle and available" corresponding to task A is not met.

[0195] Therefore, the system does not remove the waiting node corresponding to task A, nor does it perform task wake-up processing. Instead, it maintains the original arrangement position of the waiting node of task A in the unified waiting queue and continues to monitor the status of the target mutex semaphore.

[0196] For example, for a counting semaphore waiting task, if the current count value changes from 0 to 1, but the waiting task needs to acquire two resources, the system determines that the current count state change has not met the synchronization constraint condition and does not perform task recovery processing.

[0197] Subsequently, the system continues to read the target semaphore status information and performs the next cycle status verification based on the synchronization constraint parameters in the waiting node.

[0198] Preferably, the current state of the target semaphore is periodically checked according to the synchronization constraint parameters to determine whether the current resource state meets the wake-up condition corresponding to the waiting task. Read the current state information of the target semaphore and extract the synchronization constraint parameters corresponding to the waiting node; The synchronization constraint parameters are matched with the current state of the target semaphore to determine whether the current resource state meets the resource acquisition conditions of the corresponding task. When the current state of the target semaphore meets the synchronization constraint, the corresponding waiting node is marked as recoverable and enters the task wake-up process. When the current state of the target semaphore does not meet the synchronization constraints, the waiting node remains in a blocked state and its association in the unified waiting queue is retained.

[0199] In some embodiments, the semaphore wait task status detection process in a real-time operating system is used as an example.

[0200] During system operation, task A requests to acquire a target mutex semaphore. Since the mutex semaphore is currently occupied by task B, the system determines that task A cannot acquire the resource immediately based on the mutex semaphore acquisition conditions and adds the corresponding waiting node of task A to a unified waiting queue.

[0201] Specifically, the system first reads the current state information of the target semaphore and extracts the synchronization constraint parameters corresponding to the waiting nodes.

[0202] For example, when the target semaphore is a mutex semaphore, the system reads the current state information in the mutex semaphore control structure, including the current occupant identifier and the resource occupancy status. Simultaneously, the system reads the synchronization constraint parameters in the waiting node corresponding to task A. These synchronization constraint parameters describe the conditions that task A needs to meet to resume execution, such as "the occupant identifier is null and the resource is in a released state."

[0203] If the target semaphore is a counting semaphore, the system reads the current counting status information, including the current count value and the remaining amount of resources, and extracts the counting resource requirement conditions recorded in the waiting node, such as "the current count value is greater than or equal to the task requirement quantity".

[0204] If the target semaphore is a read / write semaphore, the system reads the current read / write status information, including the current number of read tasks and the write task occupancy status, and extracts the access permission constraints from the corresponding waiting node.

[0205] Furthermore, the system matches the synchronization constraint parameters with the current state of the target semaphore to determine whether the current resource state meets the resource acquisition conditions for the corresponding task.

[0206] For example, for task A waiting for a mutex semaphore, the system matches the occupant identifier in the current mutex semaphore state with the synchronization constraint parameters.

[0207] When it is detected that the current occupant identifier still corresponds to task B, it means that the mutual exclusive resource is still in an occupied state, which does not match the "resource release" synchronization constraint in the waiting node of task A. Therefore, it is determined that the current resource state does not meet the recovery condition of task A.

[0208] When the system detects that task B has released the mutex semaphore, it reads the target mutex semaphore status information again and finds that the occupant identifier has been cleared and the resource status has changed to idle. Then it determines that the current status meets the resource acquisition conditions corresponding to task A.

[0209] For example, for task C waiting for a counting semaphore, the system reads the current count value. If the synchronization constraint parameter in the waiting node indicates that task C needs to acquire at least two resources, but the current count value is only one, the system determines that the current counting state does not meet the wake-up condition. When subsequent resource release increases the count value to two or more, the system determines that the resource acquisition condition of task C is met.

[0210] Furthermore, when the current state of the target semaphore meets the synchronization constraint conditions, the system marks the corresponding waiting node as recoverable and enters the task wake-up process.

[0211] For example, when the mutex semaphore that task A is waiting for changes from an occupied state to an idle state, the system updates the task status identifier in the waiting node corresponding to task A from a blocked state to a recoverable state based on the synchronization constraint matching result.

[0212] Subsequently, based on the target semaphore identifier associated with the waiting node, the system removes the association between task A and the waiting state of the target mutex semaphore, and adds task A to the task scheduling processing sequence.

[0213] For example, when task C waiting for the counting semaphore meets the resource quantity condition, the system updates the status of the waiting node corresponding to task C and calls the task recovery processing interface to enable task C to re-participate in the real-time operating system scheduling and execution.

[0214] Furthermore, when the current state of the target semaphore does not meet the synchronization constraint, the system maintains the blocked state of the waiting node and continues to retain its association in the unified waiting queue.

[0215] For example, while task A is waiting for a mutex semaphore, the system periodically checks the status of the target mutex semaphore. If it finds that the current resource is still occupied by task B, the system does not change the status of the waiting node corresponding to task A and continues to keep task A in a blocked state.

[0216] Meanwhile, the system does not delete the association between task A and the target mutex semaphore, but retains the position of the waiting node in the unified waiting queue so that condition matching can continue when the target semaphore state changes.

[0217] For example, when task C is waiting for the counting semaphore, if the current count value changes but the synchronization constraint condition corresponding to task C is still not met, the system only updates the target semaphore status detection record, does not perform the task wake-up operation, and continues to keep the waiting node corresponding to task C in the waiting state.

[0218] Preferably, when the current state of the target semaphore satisfies the synchronization constraint, the corresponding waiting node is marked as recoverable and the task wake-up process is initiated, including: Read the waiting nodes that meet the synchronization constraints, update the task status flag corresponding to the waiting node, and switch it from the waiting state to the recoverable state. Based on the target semaphore identifier associated with the waiting node, the association between the current task and the blocking state is removed, and the waiting record corresponding to the target semaphore is updated. Add waiting nodes that are in a recoverable state to the task scheduling and processing sequence, and determine the task recovery order based on the task arrangement information in the unified waiting queue; Call the task recovery processing interface to enable the corresponding task to rejoin the real-time operating system's scheduling and execution.

[0219] In some embodiments, the semaphore wait task recovery process in a real-time operating system is taken as an example.

[0220] During system operation, task A requests to acquire the target mutex semaphore. Since the mutex semaphore is currently occupied by task B, the system adds the waiting node corresponding to task A to a unified waiting queue and records the target mutex semaphore identifier and the corresponding synchronization constraint parameters in the waiting node.

[0221] For example, the synchronization constraint parameter for task A is "the occupant identifier is empty and the resource is in a released state". When task B completes resource access and releases the mutex semaphore, the system detects that the current state of the target semaphore satisfies the synchronization constraint condition corresponding to task A, and then enters the task wake-up process.

[0222] Specifically, the system first reads the waiting nodes that meet the synchronization constraints, updates the task status flag corresponding to the waiting nodes, and switches them from the waiting state to the recoverable state.

[0223] For example, the system locates the waiting node corresponding to task A based on the target mutex semaphore release event, and reads the task status field in the waiting node.

[0224] The original status of task A was "waiting," indicating that the task was blocked because it could not acquire the mutex resource. Once the system confirms that the target mutex semaphore has met the resource acquisition conditions, the corresponding status field of task A is updated to "recoverable," indicating that the task has met the conditions to continue execution.

[0225] For task C waiting for the counting semaphore, when the current count value is detected to have reached the amount of resources required by task C, the system also reads the corresponding waiting node of task C and switches the status of task C from the waiting state to the recoverable state.

[0226] Furthermore, the system removes the association between the current task and the blocking state based on the target semaphore identifier associated with the waiting node, and updates the waiting record corresponding to the target semaphore.

[0227] For example, the waiting node corresponding to task A records the identifier of the target mutex semaphore. The system uses this identifier to remove the association between task A and the blocking state of the target mutex semaphore, so that task A is no longer in the state of waiting for the mutex semaphore to be released.

[0228] At the same time, the system updates the waiting record corresponding to the target mutex semaphore.

[0229] For example, the system removes the waiting node corresponding to task A from the waiting record field in the target mutex semaphore control structure, updates the current number of waiting tasks, and refreshes the waiting queue association information.

[0230] In the case of counting semaphores, when task C meets the resource acquisition conditions, the system removes the association between task C and the waiting state of the counting resource based on the target counting semaphore identifier, and updates the waiting record corresponding to the counting semaphore.

[0231] Furthermore, the system adds waiting nodes in a recoverable state to the task scheduling processing sequence and determines the task recovery order based on the task arrangement information in the unified waiting queue.

[0232] For example, multiple task nodes waiting for the same mutex semaphore may exist simultaneously in a unified waiting queue, including task A, task D, and task E.

[0233] After the target mutex semaphore is released, the system first reads the current state of each waiting node and adds the waiting nodes that meet the synchronization constraints to the task scheduling processing sequence.

[0234] If the unified waiting queue adopts the first-in-first-out scheduling method, the system determines the task recovery order according to the entry order of the waiting nodes. For example, task A, which entered the waiting queue first, will be recovered first.

[0235] If the unified waiting queue adopts a priority scheduling method, the system reads the priority of the corresponding task of each waiting node and determines the recovery order according to the priority information. For example, the high-priority task D is recovered first.

[0236] Subsequently, the system sends the corresponding task nodes to the task scheduling and processing sequence according to the determined task recovery order.

[0237] Furthermore, the system calls the task recovery processing interface, enabling the corresponding task to re-participate in the real-time operating system's scheduling and execution.

[0238] For example, the system calls the recovery processing interface corresponding to task A, removes task A from the blocked task queue, and adds it back to the ready task queue.

[0239] When the operating system scheduler executes the next round of task scheduling, if it detects that task A is already in an executable state, it will select task A to execute according to the current scheduling policy, so that task A can continue to execute the operation that was previously suspended due to waiting for a semaphore.

[0240] For waiting tasks corresponding to multiple different types of semaphores, such as task A waiting for a mutex semaphore, task C waiting for a counting semaphore, and task D waiting for a binary semaphore, the system completes the state transition through a unified waiting node and performs recovery processing according to the corresponding synchronization constraints.

[0241] Of particular importance, step S5 includes: Read the occupant identifier and recursion count of the target mutex semaphore, and obtain the task identifier of the currently executing task to determine the occupancy relationship between the current task and the mutex semaphore; When the current task does not hold a mutex semaphore, determine whether the mutex semaphore has been occupied by another task based on the occupant identifier, and update the occupant identifier and recursive count when the resource becomes available. When the current task already holds a mutex semaphore and performs an acquisition operation again, the number of recursive occupancy times corresponding to the mutex semaphore is increased according to the recursion count. When a mutex semaphore is already occupied by another task and the current task enters a waiting state, priority inheritance is performed based on the priority states of the current task and the occupying task, and the original priority state of the occupying task is restored after the mutex semaphore is released.

[0242] In some embodiments, taking multiple periodic tasks running in a real-time operating system as an example, the system manages mutex semaphores using a unified semaphore control structure. Assume task A is currently performing a resource access operation, and task B already holds the target mutex semaphore. At this point, task A requests to acquire the mutex semaphore again.

[0243] Specifically, the system first reads the occupant identifier and recursion count from the target mutex semaphore control structure, and obtains the task identifier corresponding to the currently executing task A. The system compares the task identifier of task A with the occupant identifier to determine the occupancy relationship between the current task A and the target mutex semaphore.

[0244] When the task identifier and the occupant identifier of task A are inconsistent, the system determines that task A does not currently hold the target mutex semaphore and further reads the current occupancy status of the target mutex semaphore. If the occupant identifier is empty, it is determined that the mutex semaphore is not currently occupied by other tasks, the system updates the occupant identifier to the task identifier of task A, and initializes the recursion count to 1; if the occupant identifier already corresponds to task B, it is determined that the target mutex semaphore has been occupied by other tasks.

[0245] When task A already holds the target mutex semaphore and performs an acquisition operation again, the system detects that the current task identifier matches the holder identifier, and then reads the current recursion count. For example, when task A first acquires the mutex semaphore, the recursion count is 1. When task A performs an acquisition operation again without releasing the mutex semaphore, the system increases the recursion count from 1 to 2; the recursion count continues to increase when task A acquires it again.

[0246] When the target mutex semaphore is occupied by task B, and task A does not currently hold the mutex semaphore, the system compares the priority of task A with the current execution priority of task B. If task A's priority is higher than task B's, the system adjusts task B's current execution priority to the priority of task A, records task B's original priority state before the adjustment, and simultaneously associates the waiting node corresponding to task A with the target mutex semaphore.

[0247] After task A enters the waiting state, task B continues to hold the target mutex semaphore and runs according to the adjusted execution priority. When task B completes resource access and performs a release operation, the system reads the recursive count of the target mutex semaphore; when the recursive count is 1, the occupant identifier is cleared and the mutex semaphore is updated to the idle state. At the same time, the original priority state saved by task B is read, and the execution priority of task B is restored to the state before the priority adjustment.

[0248] Subsequently, the system determines task A based on the waiting nodes in the unified waiting queue, and restores task A to the executable state according to the scheduling order corresponding to the waiting queue, so that task A can re-participate in the task scheduling of the real-time operating system.

[0249] Most importantly, when a mutex semaphore is already occupied by another task and the current task enters a waiting state, priority inheritance processing is performed based on the priority states of the current task and the occupying task. Specifically, this includes: Get the priority of the currently waiting task and the priority of the occupying task corresponding to the mutex semaphore, and establish the priority inheritance association between the currently waiting task and the occupying task based on the occupant identifier; When the priority of the currently waiting task is higher than the current priority of the occupying task, the priority of the currently waiting task is written into the inherited priority state of the occupying task, and the execution priority of the occupying task is adjusted according to the inherited priority state. While the mutex semaphore is in an occupied state, the association between the inherited priority state and the corresponding occupant identifier is maintained, and the current inherited state is not directly overwritten when other waiting tasks join. When the occupier releases the mutex semaphore, the corresponding priority inheritance association is released according to the occupier identifier, and the execution priority of the occupier is re-determined according to the priority status of the remaining waiting tasks.

[0250] In some embodiments, task A, task B, and a target mutex semaphore in a real-time operating system are used as an example. Task B currently holds the target mutex semaphore and is executing a resource access task. During its execution, task A requests to acquire the same mutex semaphore. Since the target mutex semaphore is already occupied by task B, task A cannot immediately acquire the resource and is therefore added to a unified waiting queue and enters a waiting state.

[0251] Specifically, the system first reads the task priority from the task control information corresponding to task A, and then reads the task priority of the currently occupying task B based on the occupant identifier in the target mutex semaphore control structure. For example, the current priority of task A is 10, and the current priority of task B is 50. The system determines task B as the currently occupying task based on the occupant identifier of the target mutex semaphore, establishes a priority inheritance association between task A and task B, records task A as a waiting task, and records task B as the corresponding occupying task.

[0252] When the system detects that task A's priority is higher than task B's current priority, it writes task A's priority into task B's inherited priority state. For example, it writes task A's priority of 10 into task B's inherited priority field and adjusts task B's current execution priority from 50 to 10, allowing task B to continue execution according to the adjusted priority. Simultaneously, the system records the original priority of 50 in task B's task control information for later restoration when the mutex semaphore is released.

[0253] While the target mutex semaphore is held by task B, the system maintains the association between task B's inherited priority state and the mutex semaphore holder identifier. If task C also requests to acquire the mutex semaphore and enters a waiting state, the system reads task C's priority and compares it with task B's current inherited priority. For example, if task C's priority is 20, and task B is currently executing according to task A's priority of 10, the system does not directly use task C's priority to overwrite task B's current inherited priority. Instead, it maintains the established priority inheritance association between task B and task A, and records task C as a new waiting task in the unified waiting queue.

[0254] When task B completes resource access and releases the target mutex semaphore, the system first determines that the currently releasing task is task B based on the occupant identifier in the mutex semaphore control structure, and then removes the priority inheritance association established between task B and task A. Subsequently, the system reads the priority information corresponding to tasks A and C that are still in a waiting state in the unified waiting queue, and re-determines the execution priority of task B according to the priority of the waiting tasks.

[0255] For example, after task A has met the conditions for acquiring the mutex semaphore and been removed from the waiting queue, if task C is still in a waiting state, the system re-determines the execution priority of task B based on the priority of the remaining waiting task C. If there are no other waiting tasks, the system reads the original priority of 50 saved before task B was released and restores the execution priority of task B to 50. Subsequently, the system updates the inherited priority status of task B and removes the corresponding priority inheritance record.

[0256] Therefore, the embodiments should be considered as exemplary and non-limiting in all respects, and the scope of the invention is defined by the appended claims rather than the foregoing description. Thus, all variations falling within the meaning and scope of the equivalents of the application are intended to be included within the invention.

[0257] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features of the invention herein.

Claims

1. A method for managing multiple types of semaphores in a real-time operating system, characterized in that, Includes the following steps: Step S1: Establish a unified semaphore control structure to perform unified abstract management of binary semaphores, counting semaphores, mutex semaphores and read / write semaphores. The unified semaphore control structure includes semaphore type identifier, status information, configuration options and waiting queue. Step S2: Receive an acquisition operation request or a release operation request for the target semaphore, and generate a type index based on the semaphore type identifier of the target semaphore; Step S3: Call the matching processing function from the corresponding type processing dispatch table according to the type index, and perform an acquisition operation or a release operation on the target semaphore. The type processing dispatch table includes an acquisition processing dispatch table, a release processing dispatch table, and a refresh processing dispatch table. Step S4: When the resource status corresponding to the acquisition operation does not meet the task execution conditions, add the current task to the waiting queue, and wake up the waiting task according to the queue scheduling strategy when the resource status meets the conditions. Step S5: When the target semaphore is a mutex semaphore, mutual exclusion control is performed based on the occupant identifier and recursive count in the status information, and priority inheritance processing is performed based on the task priority status adjustment.

2. The method for managing multiple types of semaphores in a real-time operating system according to claim 1, characterized in that, Step S3 includes the following steps: Step S31: Obtain the type index corresponding to the target semaphore, wherein the type index is obtained by performing logical operations on the type identifier and type mask in the target semaphore control structure; Step S32: Determine the corresponding type processing table based on the currently received operation request type, wherein the type processing table includes releasing the operation table, obtaining the operation table, and refreshing the operation table; Step S33: Based on the type index, read the address of the target processing function from the corresponding type processing dispatch table, and call the target processing function to perform corresponding operation synchronization processing on the target semaphore.

3. The method for managing multiple types of semaphores in a real-time operating system according to claim 2, characterized in that, After calling the target processing function to perform corresponding operations and synchronization processing on the target semaphore, the following also includes: Read the current state information in the target semaphore control structure, including the counting state or the occupied state, and determine the corresponding state update method according to the current operation type; When a request to acquire is received, the current resource status is assessed based on the target semaphore type: for counting semaphores, the remaining resource quantity is determined based on the current count value; for mutex semaphores, the resource occupancy status is determined based on the occupant identifier. When the current resource status meets the acquisition conditions, update the status information corresponding to the target semaphore and complete the synchronization association between the current task and the target semaphore; When the current resource status does not meet the acquisition conditions, the current task information is written to a unified waiting queue, and the task waiting order is recorded according to the scheduling method configured in the waiting queue. After the target semaphore is released, based on the updated resource status after the release operation, the corresponding task is selected from the unified waiting queue to perform the wake-up process and restore the execution status of the task.

4. The method for managing multiple types of semaphores in a real-time operating system according to claim 2, characterized in that, Methods for obtaining type indexes include: Read the type identifier field in the target semaphore control structure. The type identifier field is used to characterize the type of the target semaphore. The semaphore type includes at least binary semaphore, mutex semaphore, counting semaphore, and read / write semaphore. Perform a validity check on the type identifier field to determine whether the type identifier field is within the preset semaphore type range; Obtain the type mask corresponding to the type identifier field, and perform logical operations between the type identifier field and the type mask to extract the valid type bits in the type identifier field; The valid type bits are converted to the corresponding type index, and the type index is used as the index parameter for accessing the type processing table to determine the processing function corresponding to the target semaphore.

5. The method for managing multiple types of semaphores in a real-time operating system according to claim 3, characterized in that, When the current resource status does not meet the acquisition conditions, the current task information is written to a unified waiting queue, and the task waiting order is recorded according to the scheduling method configured in the waiting queue, specifically including: Extract the task control information corresponding to the current task and associate the task control information with the waiting state of the target semaphore. The task control information includes at least the task identifier, waiting type and waiting time information. Based on the synchronization type corresponding to the target semaphore, the waiting requirements of the current task are mapped to the corresponding waiting nodes in a unified waiting queue, so that different types of semaphores can share the same waiting management entry point. Obtain the current queue organization state of the unified waiting queue, and determine the insertion position of the waiting node based on the queue strategy configured by the target semaphore. When a first-in-first-out queue is used, the waiting nodes are arranged according to the order in which the tasks enter; when a priority queue is used, the positions of the waiting nodes are adjusted according to the task priorities. After the waiting node is established, the current unavailable state of the target semaphore is written into the corresponding state field, and the association between the waiting node and the state change event of the target semaphore is established. When a change in the status of the target semaphore resource is detected, the corresponding waiting node is located according to the association relationship, and the task to be recovered is determined according to the organization status of the waiting queue.

6. The method for managing multiple types of semaphores in a real-time operating system according to claim 5, characterized in that, Based on the synchronization type corresponding to the target semaphore, the waiting requirements of the current task are mapped to the corresponding waiting nodes in a unified waiting queue, specifically including: Obtain the waiting requirement information corresponding to the current task, and determine the synchronization constraint type corresponding to the waiting requirement based on the type identifier of the target semaphore. The synchronization constraint type is used to characterize the resource release conditions that need to be met during the task waiting process. Based on the synchronization constraint type, the waiting node description information is generated, and the task identifier, target semaphore identifier and synchronization constraint type are written into the same waiting node, so that the waiting node has the ability to independently describe the waiting state of different semaphores. The waiting nodes are attached to a unified waiting queue, and a mapping relationship is established between the synchronization constraint type in the waiting nodes and the target semaphore state change event, so that the resource change event can be directly associated with the corresponding waiting task. During the operation of the unified waiting queue, the waiting tasks of different types of semaphores are identified according to the synchronization constraint type in the waiting nodes. When a target semaphore release event is detected, only the waiting nodes that meet the corresponding synchronization constraint conditions are given subsequent wake-up processing.

7. The method for managing multiple types of semaphores in a real-time operating system according to claim 6, characterized in that, The specific type of synchronization constraint corresponding to the waiting requirement is determined based on the type identifier of the target semaphore as follows: Read the type identifier in the target semaphore control structure and determine the synchronization type corresponding to the target semaphore based on the type identifier; Based on the synchronization type, the corresponding resource constraint information is extracted, and the resource occupancy status, counting status or read / write status corresponding to different semaphore types are converted into unified synchronization constraint parameters. A waiting requirement identifier is generated based on the synchronization constraint parameters, and the waiting requirement identifier is associated with the waiting node corresponding to the current task, so that the unified waiting queue can perform task matching based on the waiting requirement identifier.

8. The method for managing multiple types of semaphores in a real-time operating system according to claim 6, characterized in that, The following is also included when no target semaphore release event is detected: Maintain the association between the current waiting node and the target semaphore, and read the synchronization constraint parameters corresponding to the waiting node; The current state of the target semaphore is periodically checked based on the synchronization constraint parameters to determine whether the current resource state meets the wake-up conditions corresponding to the waiting task. When the target semaphore state does not change to meet the conditions, update the waiting state information of the waiting node and keep the current task in a blocked state. When a change in the state of the target semaphore is detected but the synchronization constraint is not met, the waiting node maintains its position in the unified waiting queue and continues to perform state monitoring.

9. The method for managing multiple types of semaphores in a real-time operating system according to claim 8, characterized in that, The current state of the target semaphore is periodically checked based on the synchronization constraint parameters to determine whether the current resource state meets the wake-up condition corresponding to the waiting task. Specifically: Read the current state information of the target semaphore and extract the synchronization constraint parameters corresponding to the waiting node; The synchronization constraint parameters are matched with the current state of the target semaphore to determine whether the current resource state meets the resource acquisition conditions of the corresponding task. When the current state of the target semaphore meets the synchronization constraint, the corresponding waiting node is marked as recoverable and enters the task wake-up process. When the current state of the target semaphore does not meet the synchronization constraints, the waiting node remains in a blocked state and its association in the unified waiting queue is retained.

10. The method for managing multiple types of semaphores in a real-time operating system according to claim 9, characterized in that, When the current state of the target semaphore satisfies the synchronization constraints, the corresponding waiting node is marked as recoverable, and the task wake-up process begins, including: Read the waiting nodes that meet the synchronization constraints, update the task status flag corresponding to the waiting node, and switch it from the waiting state to the recoverable state. Based on the target semaphore identifier associated with the waiting node, the association between the current task and the blocking state is removed, and the waiting record corresponding to the target semaphore is updated. Add waiting nodes that are in a recoverable state to the task scheduling and processing sequence, and determine the task recovery order based on the task arrangement information in the unified waiting queue; Call the task recovery processing interface to enable the corresponding task to rejoin the real-time operating system's scheduling and execution.

Images