Method and device for constructing extended semaphore in Linux environment

Abstract

The invention discloses a construction method and device for an extended semaphore in a Linux environment, and belongs to the technical field of operating systems. The method comprises the following steps: multiplexing an XSI semaphore in a Linux operating system, expanding a flag parameter of the XSI semaphore, and setting the flag parameter to be true to form an expanded semaphore; wherein the extended semaphore is provided with task processing mode attributes and a plurality of interfaces on the basis of the XSI semaphore; the task processing mode attribute characterizes that the extended semaphore accepts task access according to the task priority; the interfaces comprise a lower limit value setting interface, an upper limit value setting interface, a task waiting confirmation interface, a preemption interface, a task priority acquisition interface and an operation part success interface. According to the method, the behavior of the novel semaphore is manually expanded, so that whether the task waits for the semaphore or not is flexibly determined according to the actual condition of the current system.

Description

Technical Field

[0001] The present invention belongs to the technical field of operating systems, and particularly relates to a method and device for constructing an extended semaphore in a Linux environment. Background Art

[0002] With the increasingly widespread use of the Linux operating system in more scenarios such as embedded systems, there is an increasing demand for running tasks with different priorities or even real-time tasks. Inevitably, inter-process communication or synchronization is required between priority tasks. This generally needs to be achieved by relying on the lock mechanism or IPC mechanism provided by the Linux operating system. Among them, semaphores are mainly used to provide synchronous access control for multiple processes to shared data objects (such as a certain system resource or the consumer goods in the producer-consumer model).

[0003] However, the native semaphores in Linux mainly consider the use of ordinary users and do not particularly consider the situation of task priorities. When a task applies for a semaphore and needs to wait, the waiting tasks are directly processed in a FIFO manner. On the one hand, this may cause a high-priority task to wait for a low-priority task to finish running when applying for a semaphore because the semaphore is being used by a low-priority task. On the other hand, it may occur that both a high-priority task and a low-priority task are waiting for the semaphore, but the low-priority task applies earlier, so the low-priority task runs first. These will all lead to the priority inversion problem and even cause the entire embedded environment to run chaotically.

[0004] In addition, the existing semaphore mechanisms also have some inconveniences in scenarios with different priorities. For example, in an embedded environment, multiple tasks with different priorities often need to cooperate with each other to run. Whether a task can wait for a semaphore may need to consider the overall operating environment of the system.

[0005] In the existing Linux system, there are two commonly used semaphore mechanisms. One is the posix semaphore, and the other is the XSI semaphore based on SystemV. The functions of the two semaphores are similar. Both are associated with a semaphore value and achieve synchronization between multiple tasks by providing interfaces for atomic addition and subtraction operations on the value. When blocking and waiting are required, tasks wait in the queue in a FIFO manner, and other factors are not considered for task waiting and waking up.

[0006] In the existing semaphore mechanism, when the priorities of tasks are different, it does not support preferentially satisfying tasks with high priorities, nor does it support preemption of low-priority tasks by high-priority tasks, which easily leads to the problem of priority inversion. In addition, in some scenarios, the interface is not flexible enough. For example, if you want the Linux operating system to more flexibly decide whether a task should wait for a semaphore according to the actual situation, the existing semaphore mechanism has no solution. Another example is that if you want to apply for as many semaphores as possible, since querying and applying are two independent interfaces, it is inevitable that the actual value is inconsistent with the queried value during application, resulting in possible failure or blocking of high-priority tasks. For another example, in the producer-consumer model, if you want to limit the number of producers, since the maximum value of the semaphore cannot be restricted, it cannot be directly restricted by the semaphore. Summary of the Invention

[0007] The present invention proposes a method and device for constructing an extended semaphore in a Linux environment to solve the above-mentioned technical problem of priority inversion in the Linux operating system.

[0008] The first aspect of the present invention proposes a method for constructing an extended semaphore in a Linux environment, and the method includes: Reusing the XSI semaphore in the Linux operating system, expanding the flag parameter of the XSI semaphore, and setting the flag parameter to true to form an extended semaphore; Among them, the extended semaphore sets a task processing method attribute and multiple interfaces on the basis of the XSI semaphore; The task processing method attribute indicates that the extended semaphore accepts task access according to the task priority; The interfaces include a lower limit value setting interface, an upper limit value setting interface, a task waiting confirmation interface, a preemption interface, a task priority acquisition interface, and an operation partial success interface; Among them: The lower limit value interface is an interface for receiving the user to set the lower limit value of the extended semaphore; The upper limit value setting interface is an interface for receiving the user to set the upper limit value of the extended semaphore; The task waiting confirmation interface is an interface for the Linux operating system to determine whether the task enters the waiting state when there is a possibility that the task accessing the extended semaphore waits for the extended semaphore; The preemption interface is an interface for stopping the operation of a task with a lower priority than the task and accessing the extended semaphore when the task accessing the extended semaphore must wait for the extended semaphore; The task priority acquisition interface is an interface for acquiring the priority of a task waiting for the extended semaphore; the task accessing the extended semaphore expects to perform an expected number of operations on the extended semaphore. After updating the extended semaphore according to the expected number, when the updated extended semaphore is lower than the lower limit value, the operation partial success interface enables the task to perform a partial expected number of accesses to the extended semaphore and returns the value of the partial expected number of executions.

[0009] Preferably, tasks waiting to access the newly added semaphore are all stored in a waiting queue, and each task corresponds to a priority. This waiting queue is a prioritized queue.

[0010] Preferably, the interface for the Linux operating system to determine whether the task enters the waiting state, where: The Linux operating system determines whether the task enters the waiting state based on the current operating system task running situation or the priority of the task.

[0011] Preferably, the ways to implement stopping the operations of tasks with priorities lower than that of this task and accessing the extended semaphore include: Record the specific number of times each task has operated on the extended semaphore; This task sends a signal to tasks with priorities lower than that of this task and accessing the extended semaphore, causing the tasks accessing the extended semaphore to release the semaphore.

[0012] Preferably, when the current task performs an operation of subtracting the expected number on the extended semaphore, it includes the following steps: Step S101: The user state constructs an access parameter request based on the current task to perform an operation of subtracting the expected number on the extended semaphore, and calls the system call interface of the Linux operating system to enter the kernel state; Step S102: Determine the difference between the current value of the extended semaphore and the lower limit value. If the difference is less than the expected number, go to step S103; otherwise, go to step S107; Step S103: Determine whether the current task expects to call the operation partial success interface based on the access parameters; if not, go to step S104; if so, and the call to the operation partial success interface is successful, go to step S107; Step S104: When the non-waiting flag is set in the access parameters, return an error code and the method ends; When the non-waiting flag is not set in the access parameters, call the interface of the Linux operating system kernel to determine whether the current task can enter the waiting state. If it cannot enter the waiting state, return an error code and the method ends; if it can enter the waiting state, go to step S105; Step S105: Determine whether the parameters required for the preemption interface of the extended semaphore are set for the current task based on the access parameters; If not, proceed to step S106; If so, send a preemption signal to other tasks with a lower priority than the current task for accessing the extended semaphore. When preemption fails, proceed to step S106; when preemption succeeds, wait for the preemption to complete and then proceed to step S106; Step S106: The current task enters the waiting queue corresponding to the current task, and when the operating conditions of the semaphore required in the access parameters are met, the current task is awakened; Step S107: Check whether the current task can awaken other blocked tasks. If so, awaken the blocked tasks in order from highest to lowest priority, and for the same priority, in ascending order of the application of the extended semaphore, and then proceed to step S108; if not, proceed to step S108; Step S108: Add the current task to the priority list of the extended semaphore that has been applied for; Step S109: The current task operates on the extended semaphore and returns the operation result to the user space; return 0 to the user space.

[0013] Preferably, when the current task performs an operation of adding an expected quantity to the extended semaphore, the following steps are included: Step S201: The user state constructs an access parameter request based on the current task to perform an operation of adding an expected quantity to the extended semaphore, and calls the system call interface of the Linux operating system to enter the kernel state; Step S202: Determine the difference between the current value and the upper limit value of the extended semaphore. If the difference is less than the expected quantity, proceed to step S203; otherwise, proceed to step S205; Step S203: When the non-waiting flag is set in the access parameters, return an error code and the method ends; When the non-waiting flag is not set in the access parameters, call the interface of the Linux operating system kernel to determine whether the current task can enter the waiting state. If it cannot enter the waiting state, return an error code and the method ends; if it can enter the waiting state, proceed to step S204; Step S204: The current task enters the waiting queue corresponding to the current task, and when the operating conditions of the semaphore required in the access parameters are met, the current task is awakened; Step S205: Check whether the current task can awaken other blocked tasks. If so, awaken the blocked tasks in order from highest to lowest priority, and for the same priority, in ascending order of the application of the extended semaphore, and then proceed to step S206; if not, proceed to step S206; Step S206: If the extended semaphore held by the current task becomes 0, delete the current task from the priority list that has applied for the extended semaphore, and the method ends; otherwise, proceed to step S207; Step S207: The current task operates on the extended semaphore, returns the operation result to the user space; returns 0 to the user space.

[0014] The second aspect of the present invention proposes a construction device for extended semaphores in a Linux environment, which is based on the method described above. The device includes: An extension module: configured to multiplex the XSI semaphore in the Linux operating system, extend the flag parameter of the XSI semaphore, and set the flag parameter to true to form an extended semaphore; Among them, the extended semaphore sets task processing mode attributes and multiple interfaces on the basis of the XSI semaphore.

[0015] The third aspect of the present invention provides an electronic device, the electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the method described above.

[0016] The fourth aspect of the present invention provides a non-transitory computer-readable storage medium storing computer instructions, and the computer instructions are used to cause the computer to execute the method described above.

[0017] The present invention has the following technical effects: (1) Based on the original semaphore, the present invention realizes the support for priority tasks by extending its basic increment and decrement operations. The present invention supports the preemption of low-priority tasks by high-priority tasks, and also supports tasks waiting in the queue according to priority, and preferentially satisfies high-priority tasks.

[0018] (2) The present invention provides an extended interface to support manual extension of the behavior of new semaphores, so as to flexibly determine whether a task needs to wait for a semaphore according to the actual situation of the current system, which is particularly important for high-priority tasks or real-time tasks in embedded scenarios.

[0019] (3) When the semaphore part supported by the present invention meets the conditions, it returns successfully and allows the minimum value to be specified through parameters to set the required minimum value of the semaphore. When a high-priority task wants to obtain as many semaphores as possible, by setting a larger parameter, it is possible to avoid the situation where information is out of sync due to the independence of the query and acquisition interfaces, resulting in acquisition failure or task blocking.

[0020] (4) The present invention also supports modifying the maximum value of the semaphore and performing a maximum value check to block tasks after exceeding the maximum value. This is useful in some producer-consumer models and can prevent the over-accumulation of certain resources. A semaphore synchronization mechanism for tasks with different priorities is provided, which can better meet the task synchronization requirements of tasks with different priorities or even real-time tasks, and ensure that high-priority tasks can run first. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Figure 1 It is a schematic flow chart of the method for constructing an extended semaphore in the Linux environment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0022] To make the objectives, technical solutions, and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present disclosure. Apparently, the described embodiments are some, but not all, of the embodiments of the present disclosure. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present disclosure without creative efforts shall fall within the scope of protection of the present disclosure.

[0023] As Figure 1 shown, the present invention provides a method for constructing an extended semaphore in a Linux environment, and the method includes: Reusing the XSI semaphore in the Linux operating system, extending the flag parameter of the XSI semaphore, and setting the flag parameter to true to form an extended semaphore; Among them, the extended semaphore sets a task processing method attribute and multiple interfaces on the basis of the XSI semaphore; The task processing method attribute indicates that the extended semaphore accepts task access according to the task priority; The interfaces include a lower limit value setting interface, an upper limit value setting interface, a task waiting confirmation interface, a preemption interface, a task priority acquisition interface, and an operation partial success interface; Among them: The lower limit value interface is an interface for receiving the user to set the lower limit value of the extended semaphore; The upper limit value setting interface is an interface for receiving the user to set the upper limit value of the extended semaphore; The task waiting confirmation interface is an interface by which the Linux operating system determines whether the task accessing the extended semaphore enters the waiting state when there may be tasks waiting for the extended semaphore; The preemption interface is an interface that causes the tasks with priorities lower than that of the task accessing the extended semaphore and accessing the extended semaphore to stop operating when the task accessing the extended semaphore must wait for the extended semaphore; The task priority acquisition interface is an interface for acquiring the priorities of the tasks waiting for the extended semaphore; the task accessing the extended semaphore expects to perform an expected number of operations on the extended semaphore. After updating the extended semaphore according to the expected number, when the updated extended semaphore is lower than the lower limit value, the operation partial success interface causes the task to perform a partial number of expected accesses to the extended semaphore and returns the value of the partial number of executions.

[0024] In the present invention, for example, the lower limit value setting interface sets the lower limit value of the extended semaphore to 0. If the expected number of operations of a certain task is to decrease the value of the extended semaphore by 5, but the actual value of the extended semaphore at this time is 3, then the operation partial success interface causes the task to only decrease the value of the extended semaphore by 3, that is, the partial expected number is 3, causes the task to only perform a partial number of expected accesses to the extended semaphore, and returns the value of the partial number of executions. By means of the lower limit value setting interface, the upper limit value setting interface and the operation partial success interface, as many extended semaphores as possible can be atomically applied and blocking can be avoided as much as possible.

[0025] Furthermore, the tasks waiting to access the newly added semaphore are all stored in the waiting queue, and each task corresponds to a priority, and this waiting queue is a queue with priorities.

[0026] For the interface by which the Linux operating system determines whether the task enters the waiting state, where: The Linux operating system determines whether the task enters the waiting state based on the current operating system task running situation or the priority of the task.

[0027] The ways to cause the tasks with priorities lower than that of the task and accessing the extended semaphore to stop operating include: Recording the specific number of times each task has operated on the extended semaphore; The task sends a signal to the tasks with priorities lower than that of the task and accessing the extended semaphore, causing the tasks accessing the extended semaphore to release the semaphore.

[0028] In the present invention, a priority linked list is used to record the specific number of times each task has operated on an extended semaphore. The priority value of a task can be obtained from the parameters of the task priority acquisition interface. If the parameter is empty, the default value is the scheduling priority of the task. If the current task performs an operation of adding a certain value to an extended semaphore, and the extended semaphore corresponding to the current task has reached the maximum value, the current task needs to enter the waiting queue.

[0029] In the present invention, the waiting queues are all priority waiting queues, which will give priority to tasks with high priorities. It is also possible not to follow the first-in, first-out method, so that in the waiting queues with the same priority, operations are performed in the order of the application of extended semaphores from small to large. The extended semaphore supports the preemption of low-priority tasks by high-priority tasks, and can make low-priority tasks actively give up the extended semaphore, so as to give priority to high-priority tasks. Low-priority tasks are preempted in the order of the application of extended semaphores from large to small with the same priority.

[0030] Further, when the current task performs an operation of subtracting an expected quantity from an extended semaphore, the following steps are included: Step S101: The user state constructs an access parameter request based on the current task to perform an operation of subtracting an expected quantity from the extended semaphore, and calls the system call interface of the Linux operating system to enter the kernel state; Step S102: Determine the difference between the current value and the lower limit value of the extended semaphore. If the difference is less than the expected quantity, go to step S103; otherwise, go to step S107; Step S103: Determine whether the current task expects to call the operation partial success interface based on the access parameters; if not, go to step S104; if so, and the call to the operation partial success interface is successful, go to step S107; Step S104: When the non-waiting flag is set in the access parameters, return an error code and the method ends; When the non-waiting flag is not set in the access parameters, call the interface of the Linux operating system kernel to determine whether the current task can enter the waiting state. If it cannot enter the waiting state, return an error code and the method ends; if it can enter the waiting state, go to step S105; Step S105: Determine whether the current task has set the parameters required for the preemption interface of the extended semaphore based on the access parameters; If not, go to step S106; If so, send a preemption signal to other tasks with a lower priority than the current task accessing the extended semaphore. When the preemption fails, go to step S106; when the preemption is successful, wait for the preemption to complete and go to step S106; Step S106: The current task enters the waiting queue corresponding to the current task, and when the operation conditions of the semaphore required in the access parameters are met, the current task is awakened; Step S107: Check whether the current task can awaken other blocked tasks. If so, the blocked tasks are awakened in order from highest to lowest priority, and for the same priority, in ascending order of the application of the extended semaphore. Then enter step S108; if not, enter step S108; Step S108: Add the current task to the priority list that has applied for the extended semaphore; Step S109: The current task operates on the extended semaphore, returns the operation result to the user space; returns 0 to the user space.

[0031] In the present invention, the purpose of returning 0 to the user space is to tell the task in the user space that the semaphore operation is successful. In step S105: when preemption is successful and it enters step S106, the time to wait for the operation conditions of the semaphore required in the access parameters to be met is very short, only the time when other tasks release the semaphore, which is much shorter than the waiting time in other cases.

[0032] Further, when the current task performs an operation of adding an expected quantity to the extended semaphore, it includes the following steps: Step S201: The user state constructs an access parameter request based on the current task to perform an operation of adding an expected quantity to the extended semaphore, and calls the system call interface of the Linux operating system to enter the kernel state; Step S202: Determine the difference between the current value and the upper limit value of the extended semaphore. If the difference is less than the expected quantity, enter step S203; otherwise, enter step S205; Step S203: When the non-waiting flag is set in the access parameters, return an error code and the method ends; When the non-waiting flag is not set in the access parameters, call the interface of the Linux operating system kernel to determine whether the current task can enter the waiting state. If it cannot enter the waiting state, return an error code and the method ends; if it can enter the waiting state, enter step S204; Step S204: The current task enters the waiting queue corresponding to the current task, and when the operation conditions of the semaphore required in the access parameters are met, the current task is awakened; Step S205: Check whether the current task can awaken other blocked tasks. If so, the blocked tasks are awakened in order from highest to lowest priority, and for the same priority, in ascending order of the application of the extended semaphore. Then enter step S206; if not, enter step S206; Step S206: If the extended semaphore held by the current task becomes 0, delete the current task from the priority list that has applied for the extended semaphore, and the method ends; otherwise, proceed to Step S207; Step S207: The current task operates on the extended semaphore, returns the operation result to the user space; returns 0 to the user space.

[0033] Furthermore, the process of the extended semaphore waiting for its specific value to be 0 is as follows: Step S301: The user state constructs an access parameter request based on the current task to operate on the extended semaphore, and calls the system call interface of the Linux operating system to enter the kernel state; Step S302: When the value of the extended semaphore is 0, return 0 to the user space, and the method ends; otherwise, proceed to Step S303; Step S303: The current task enters the waiting queue corresponding to the priority of the current task, waits until the value of the extended semaphore is 0, or waits to be woken up by other tasks; returns 0 to the user space.

[0034] In the present invention, the Linux operating system kernel provides an interface to facilitate manually modifying the judgment function of whether the current task can wait. For other query interfaces, only function adaptation is performed without function modification.

[0035] The following describes the apparatus for implementing the present invention. For its specific implementation process and technical effects, refer to the above, and will not be elaborated below.

[0036] Optionally, the present invention provides a construction apparatus for an extended semaphore in a Linux environment based on the method described above. The apparatus includes: An extension module: configured to multiplex the XSI semaphore in the Linux operating system, extend the flag parameter of the XSI semaphore, and set the flag parameter to true to form an extended semaphore; Among them, the extended semaphore sets a task processing mode attribute and multiple interfaces on the basis of the XSI semaphore.

[0037] The above-mentioned modules may be one or more integrated circuits configured to implement the above methods. For example: one or more Application Specific Integrated Circuits (ASICs), or, one or more digital signal processors (DSPs), or, one or more Field Programmable Gate Arrays (FPGAs), etc. Again, when a certain module above is implemented in the form of processing element scheduler code, the processing element may be a general-purpose processor, such as a Central Processing Unit (CPU) or other processors that can call program code. Again, these modules may be integrated together and implemented in the form of a system-on-a-chip (SOC).

[0038] The above-mentioned modules may be connected or communicate with each other via wired connections or wireless connections. Wired connections may include metal cables, optical cables, hybrid cables, etc., or any combination thereof. Wireless connections may include connections in the form of LAN, WAN, Bluetooth, ZigBee, or NFC, etc., or any combination thereof. Two or more modules may be combined into a single module, and any one module may be divided into two or more units. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems and devices described above may refer to the corresponding processes in the method embodiments, and will not be elaborated in the present invention.

[0039] It should be noted that the above-mentioned modules may be one or more integrated circuits configured to implement the above methods. For example: one or more Application Specific Integrated Circuits (ASICs), or, one or more Digital Singnal Processors (DSPs), or, one or more Field Programmable Gate Arrays (FPGAs), etc. Again, when a certain module above is implemented in the form of processing element scheduler code, the processing element may be a general-purpose processor, such as a Central Processing Unit (CPU) or other processors that can call program code. Again, these modules may be integrated together and implemented in the form of a System-on-a-chip (SOC).

[0040] The electronic device includes a processor, a memory, a communication interface, a display screen, and an input device connected through a system bus. Among them, the processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The communication interface of the electronic device is used to communicate with an external terminal in a wired or wireless manner. The wireless manner can be achieved through WIFI, a carrier network, near field communication (NFC), or other technologies. The display screen of the electronic device can be a liquid crystal display screen or an electronic ink display screen. The input device of the electronic device can be a touch layer covering the display screen, or a button, a trackball, or a touchpad provided on the housing of the electronic device, or an external keyboard, touchpad, or mouse, etc.

[0041] The present invention also provides a program product, such as a computer-readable storage medium, including a program that is used to execute the above method embodiments when executed by a processor.

[0042] In several embodiments provided by the present invention, it should be understood that the disclosed device and method can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection between each other can be through some interfaces. The indirect coupling or communication connection of the device or unit can be in an electrical, mechanical, or other form.

[0043] The units described as separate components may or may not be physically separated. The components displayed as units may or may not be physical units, that is, they can be located in one place, or they can be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0044] In addition, each functional unit in various embodiments of the present invention can be integrated in a processing unit, or each unit can exist physically alone, or two or more units can be integrated in one unit. The above integrated unit can be implemented in the form of hardware, or in the form of a hardware plus a software functional unit.

[0045] The integrated units implemented in the form of software functional units can be stored in a computer-readable storage medium. The above-mentioned software functional units are stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) or a processor (English: processor) to execute some steps of the methods described in various embodiments of the present invention. The foregoing storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard disks, read-only memories (English: Read-Only Memory, abbreviated as: ROM), random access memories (English: Random Access Memory, abbreviated as: RAM), magnetic disks, or optical discs.

Claims

1. A method for constructing an extended semaphore in a Linux environment, characterized in that, The method includes: Reusing the XSI semaphore in the Linux operating system, expanding the flag parameter of the XSI semaphore, and setting the flag parameter to true to form an extended semaphore; Among them, the extended semaphore sets a task processing method attribute and multiple interfaces on the basis of the XSI semaphore; The task processing method attribute indicates that the extended semaphore accepts task access according to the task priority; The interfaces include a lower limit value setting interface, an upper limit value setting interface, a task waiting confirmation interface, a preemption interface, a task priority acquisition interface, and an operation partial success interface; Among them: The lower limit value interface is an interface for receiving the lower limit value of the extended semaphore set by the user; The upper limit value setting interface is an interface for receiving the upper limit value of the extended semaphore set by the user; The task waiting confirmation interface is an interface for the Linux operating system to determine whether the task enters the waiting state when there is a possibility that the task accessing the extended semaphore is waiting for the extended semaphore; The preemption interface is an interface for stopping the operation of a task with a lower priority than this task and accessing the extended semaphore when the task accessing the extended semaphore must wait for the extended semaphore; The task priority acquisition interface is an interface for acquiring the priority of the task waiting for the extended semaphore; when the task accessing the extended semaphore expects to perform an expected number of operations on the extended semaphore, after updating the extended semaphore according to the expected number, when the updated extended semaphore is lower than the lower limit value, the operation partial success interface enables the task to perform a partial expected number of accesses to the extended semaphore and returns the value of the partial expected number executed.

2. The method according to claim 1, characterized in that Tasks waiting to access the newly added semaphore are all stored in the waiting queue, and each task corresponds to a priority, and this waiting queue is a queue with priorities.

3. The method according to claim 1, characterized in that, The interface for the Linux operating system to determine whether the task enters the waiting state, among which: The Linux operating system determines whether the task enters the waiting state based on the current operating system task running situation or the priority of this task.

4. The method according to claim 1, characterized in that, The method for implementing the operation stop of a task with a lower priority than this task and accessing the extended semaphore includes: Recording the specific number of times each task has operated on the extended semaphore; Sending a signal from this task to a task with a lower priority than this task and accessing the extended semaphore to enable the task accessing the extended semaphore to release the semaphore.

5. The method according to claim 4, wherein When the current task performs an operation of subtracting the expected number on the extended semaphore, it includes the following steps: Step S101: The user state constructs an access parameter request based on the current task to perform an operation of subtracting the expected number on the extended semaphore, and calls the system call interface of the Linux operating system to enter the kernel state; Step S102: Determine the difference between the current value of the extended semaphore and the lower limit value. If the difference is less than the expected number, enter step S103; otherwise, enter step S107; Step S103: Determine whether the current task expects to call the operation partial success interface based on the access parameters; if not, enter step S104; if so, and the call to the operation partial success interface is successful, enter step S107; Step S104: When the non-waiting flag is set in the access parameters, return an error code, and the method ends; When the flag indicating cannot wait is not set in the access parameter, an interface of the Linux operating system kernel is called to determine whether the current task can enter the waiting state. If the current task cannot enter the waiting state, an error code is returned and the method ends; if the current task can enter the waiting state, step S105 is entered. Step S105: Determine whether the parameters required for the preemption interface of the extended semaphore are set for the current task based on the access parameter. If not, step S106 is entered. If so, a preemption signal is sent to other tasks whose priority for accessing the extended semaphore is lower than that of the current task. When the preemption fails, step S106 is entered; when the preemption succeeds, wait for the preemption to complete and enter step S106. Step S106: The current task enters the waiting queue corresponding to the current task, and when the operation conditions of the semaphore required in the access parameter are met, the current task is woken up. Step S107: Check whether the current task can wake up other blocked tasks. If so, the blocked tasks are woken up in order from highest to lowest priority, and for tasks with the same priority, in ascending order of the application of the extended semaphore, and step S108 is entered; if not, step S108 is entered. Step S108: Add the current task to the priority list of the extended semaphore that has been applied for. Step S109: The current task operates on the extended semaphore, returns the operation result to the user space; returns 0 to the user space.

6. The method according to claim 4, wherein When the current task performs an operation of adding an expected quantity to the extended semaphore, it includes the following steps: Step S201: In user mode, based on the current task, construct an access parameter request to perform an operation of adding an expected quantity to the extended semaphore, and call the system call interface of the Linux operating system to enter the kernel mode. Step S202: Determine the difference between the current value and the upper limit value of the extended semaphore. If the difference is less than the expected quantity, step S203 is entered; otherwise, step S205 is entered. Step S203: When the flag indicating cannot wait is set in the access parameter, an error code is returned and the method ends. When the flag indicating cannot wait is not set in the access parameter, an interface of the Linux operating system kernel is called to determine whether the current task can enter the waiting state. If the current task cannot enter the waiting state, an error code is returned and the method ends; if the current task can enter the waiting state, step S204 is entered. Step S204: The current task enters the waiting queue corresponding to the current task, and when the operation conditions of the semaphore required in the access parameter are met, the current task is woken up. Step S205: Check whether the current task can wake up other blocked tasks. If so, the blocked tasks are woken up in order from highest to lowest priority, and for tasks with the same priority, in ascending order of the application of the extended semaphore, and step S206 is entered; if not, step S206 is entered. Step S206: If the extended semaphore held by the current task becomes 0, delete the current task from the priority list of the extended semaphore that has been applied for, and the method ends; otherwise, step S207 is entered. Step S207: The current task operates on the extended semaphore, returns the operation result to the user space; returns 0 to the user space.

7. An apparatus for constructing an extended semaphore in a Linux environment, which is based on the method according to any one of claims 1-6, characterized in that The device includes: Expansion module: Configured to multiplex XSI semaphores in the Linux operating system, expand the flag parameter of the XSI semaphore, and set the flag parameter to true to form an extended semaphore; Among them, the extended semaphore sets task processing mode attributes and multiple interfaces based on the XSI semaphore.

8. An electronic device, characterized in that, The device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method according to any one of claims 1-6.

9. A non-transitory computer-readable storage medium storing computer instructions, characterized in that, The computer instructions are used to cause the computer to execute the method according to any one of claims 1-6.

Images