A method and device for constructing an extended semaphore in a Linux environment

Abstract

The application discloses a construction method and device of an extended semaphore under 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, extending a flag parameter of the XSI semaphore, setting the flag parameter to true, and forming an extended semaphore; wherein the extended semaphore is provided with a task processing mode attribute and a plurality of interfaces on the basis of the XSI semaphore; the task processing mode attribute represents that the extended semaphore accepts task access according to a 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.The application supports manual extension of behaviors of the new semaphore, so that whether a task needs to wait for the semaphore can be flexibly determined according to actual conditions of a current system.

Description

TECHNICAL FIELD

[0001] The present application belongs to the technical field of operating system, and particularly relates to a construction method and device of extended semaphore under Linux environment. BACKGROUND

[0002] With the increasingly wide use of Linux operating system in more scenarios such as embedded systems, the demand for running tasks of different priorities or even real-time tasks is also increasing. It is inevitable to need inter-process communication or synchronization between priority tasks. This generally needs to rely on the lock mechanism or IPC mechanism provided by the Linux operating system to achieve. Among them, the semaphore is mainly used to provide synchronization access control for multiple processes to shared data objects (such as certain system resources or consumer goods in the producer-consumer model).

[0003] However, the original semaphore of Linux mainly considers the use of ordinary users and does not specially consider the priority of tasks. When a task applies for a semaphore and needs to wait, the waiting task is directly processed in a FIFO manner. On the one hand, this may cause a high-priority task to apply for a semaphore, because the semaphore is being used by a low-priority task, so that the high-priority task waits for the low-priority task to end. On the other hand, a high-priority task and a low-priority task may both wait for the semaphore, but the low-priority task applies earlier, so the low-priority task runs first. These will cause priority inversion problem, and even cause the running chaos of the entire embedded environment.

[0004] In addition, the existing semaphore mechanism also has some inconvenient places in the scenario of different priorities. For example, in the embedded environment, multiple tasks of 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 running 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 of which are associated with a semaphore value, and the atomic addition and subtraction operations of the value are provided to realize the synchronization between multiple tasks. When blocking and waiting are needed, the tasks are in the queue in a FIFO manner, and the waiting and waking up of the tasks do not consider other factors.

[0006] The existing semaphore mechanism does not support priority satisfaction of high-priority tasks and preemption of high-priority tasks to low-priority tasks when priorities of tasks are different, and is prone to cause priority inversion problem. In addition, the interface is not flexible enough in some scenarios. For example, if it is desired to more flexibly determine whether a task needs to wait for a semaphore according to actual conditions by the Linux operating system, the existing semaphore mechanism has no solution. For another example, if it is desired to apply as many semaphores as possible, due to the fact that the query and application are two independent interfaces, the actual value and the query value are inevitably inconsistent when the application is performed, which leads to the possibility that a high-priority task fails or blocks. For another example, in a producer-consumer model, if it is desired to limit the number of producers, due to the fact that the maximum value of the semaphore cannot be limited, the semaphore cannot be directly used to limit. SUMMARY

[0007] The application provides a construction method and device of an extended semaphore in a Linux environment, to solve the technical problem of priority inversion of the Linux operating system.

[0008] The application provides a construction method of an extended semaphore in a Linux environment, and the method comprises the following steps:

[0009] The XSI semaphore in the Linux operating system is multiplexed, the flag parameter of the XSI semaphore is extended, and the flag parameter is set to true, to form an extended semaphore;

[0010] The extended semaphore is provided with a task processing mode attribute and a plurality of interfaces on the basis of the XSI semaphore.

[0011] The task processing mode attribute indicates that the extended semaphore accepts task access according to a task priority.

[0012] 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.

[0013] In the application, the lower limit value setting interface is an interface for receiving user setting of a lower limit value of the extended semaphore.

[0014] The upper limit value setting interface is an interface for receiving user setting of an upper limit value of the extended semaphore.

[0015] The task waiting confirmation interface is an interface for determining, by the Linux operating system, whether a task enters a waiting state when the task exists in a situation of possibly waiting for the extended semaphore.

[0016] The preemption interface is an interface for preemption of a high-priority task to a low-priority task.

[0017] The preemption interface is an interface that stops operation of a task with a priority lower than that of the task and accessing the extended semaphore in the case that the task accessing the extended semaphore has to wait for the extended semaphore;

[0018] The task priority acquisition interface is an interface that acquires 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, and after the extended semaphore is updated by 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 expected number of accesses to the extended semaphore and returns a value of the partial expected number of operations performed.

[0019] Preferably, the tasks waiting for access to the new semaphore are all stored in a waiting queue, each task corresponding to a priority, and the waiting queue is a priority queue.

[0020] Preferably, the interface for determining whether the task enters a waiting state by the Linux operating system, wherein:

[0021] The Linux operating system determines whether the task enters a waiting state based on a current operating system task running condition or a priority of the task.

[0022] Preferably, the manner of stopping operation of a task with a priority lower than that of the task and accessing the extended semaphore includes:

[0023] The specific number of operations of the extended semaphore by each task is recorded;

[0024] The task sends a signal to a task with a priority lower than that of the task and accessing the extended semaphore, so that the task accessing the extended semaphore releases the semaphore.

[0025] Preferably, when the current task performs a decrement operation of the expected number on the extended semaphore, the following steps are included:

[0026] Step S101: A user state constructs an access parameter request based on a current task to perform a decrement operation of an expected number on an extended semaphore, and calls a system call interface of a Linux operating system to enter a kernel state;

[0027] Step S102: A difference between a current value of the extended semaphore and a lower limit value is determined, and if the difference is less than the expected number, step S103 is entered; otherwise, step S107 is entered;

[0028] Step S103: Whether the current task expects to call an operation partial success interface is determined based on the access parameter; if not, step S104 is entered; if yes, and the operation partial success interface is successfully called, step S107 is entered;

[0029] Step S104: When the non-waiting identifier is set in the access parameter, an error code is returned, and the method ends;

[0030] When the non-waiting identifier is not set in the access parameter, an interface of a Linux operating system kernel is called to determine whether the current task can enter a 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;

[0031] Step S105: Based on the access parameter, it is determined whether the current task is set with parameters required by a preemption interface of the extended semaphore;

[0032] If not, step S106 is entered;

[0033] If yes, a preemption signal is sent to other tasks with a priority lower than that of the current task for accessing the extended semaphore, when the preemption is not successful, step S106 is entered; when the preemption is successful, the preemption is waited for completion, and step S106 is entered;

[0034] Step S106: The current task enters a waiting queue corresponding to the current task, and when an operation condition of a semaphore required in the access parameter is met, the current task is woken up;

[0035] Step S107: It is checked whether the current task can wake up other blocked tasks, if yes, the blocked tasks are woken up in a priority from high to low, and in the same priority, the blocked tasks are woken up in an order from small to large for applying the extended semaphore, and step S108 is entered; if not, step S108 is entered;

[0036] Step S108: The current task is added to a priority list of tasks that have applied the extended semaphore;

[0037] Step S109: The current task performs an operation on the extended semaphore, and an operation result is returned to a user space; 0 is returned to the user space.

[0038] Preferably, when the current task performs an operation of adding an expected number on the extended semaphore, the following steps are included:

[0039] Step S201: A user state constructs an access parameter based on a current task to request an operation of adding an expected number on the extended semaphore, and a system call interface of a Linux operating system is called to enter a kernel state;

[0040] Step S202: A difference between a current value and an upper limit value of the extended semaphore is determined, if the difference is less than the expected number, step S203 is entered; otherwise, step S205 is entered;

[0041] Step S203: When the non-waiting identifier is set in the access parameter, an error code is returned, and the method ends;

[0042] When the non-waitable identifier 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 a 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;

[0043] Step S204: The current task enters a waiting queue corresponding to the current task, and when an operation condition of a semaphore required in the access parameter is met, the current task is woken up;

[0044] Step S205: It is checked whether the current task can wake up other blocked tasks, if yes, the blocked tasks are woken up in order of priority from high to low and in order of application of the extended semaphore from small to large in the same priority, and step S206 is entered; if no, step S206 is entered;

[0045] Step S206: If the extended semaphore held by the current task becomes 0, the current task is deleted from a priority list of tasks that have applied the extended semaphore, and the method ends; otherwise, step S207 is entered;

[0046] Step S207: The current task performs an operation on the extended semaphore, and returns an operation result to a user space; 0 is returned to the user space.

[0047] The second aspect of the present application provides a construction device of an extended semaphore in a Linux environment, which is used in the method as described above, and the device comprises:

[0048] An extension module is configured to multiplex an XSI semaphore in the Linux operating system, extend a flag parameter of the XSI semaphore, and set the flag parameter to true to form an extended semaphore.

[0049] The extended semaphore sets a task processing mode attribute and a plurality of interfaces on the basis of the XSI semaphore.

[0050] The third aspect of the present application provides an electronic device, which comprises:

[0051] at least one processor; and

[0052] a memory in communication connection with the at least one processor; wherein

[0053] 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 as described above.

[0054] The fourth aspect of the present application provides a non-transitory computer readable storage medium storing computer instructions for causing a computer to perform the method as described above.

[0055] The present application has the following technical effects:

[0056] (1) The present application realizes the support for priority tasks by extending the basic increment and decrement operations on the basis of the original semaphore. The present application supports the preemption of low-priority tasks by high-priority tasks, and also supports the waiting of tasks in a queue according to priority, and the priority satisfaction of high-priority tasks.

[0057] (2) The present application provides an extension interface, supports the manual extension of the behavior of the new semaphore, and flexibly decides 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.

[0058] (3) The present application supports the return of success in the case of partial satisfaction of the semaphore, and allows the setting of the minimum value of the required semaphore by specifying the minimum value through a parameter. When a high-priority task wants to acquire as many semaphores as possible, a larger parameter can be set to avoid the out-of-sync of information due to the independent query and acquisition interfaces, and the resulting acquisition failure or task blocking.

[0059] (4) The present application also supports the modification of the maximum value of the semaphore, and performs maximum value checking to block the task after exceeding the maximum value, which is useful in some producer-consumer models and can prevent the excessive accumulation of some resources.

[0060] A semaphore synchronization mechanism for different priority tasks is provided, which can better meet the task synchronization needs of different priority tasks or even real-time tasks, and ensure that high-priority tasks can be given priority to run. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 FIG. 1 is a flowchart of the construction method of the extended semaphore in the Linux environment of the present application. DETAILED DESCRIPTION

[0062] To make the purposes, technical solutions, and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be described clearly and completely below with reference to the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are only a part of the embodiments of the present disclosure, rather than all the embodiments of the present disclosure. Based on the embodiments in the present disclosure, all other embodiments obtained by those of ordinary skill in the art without creative work belong to the scope of protection of the present disclosure.

[0063] As Figure 1As shown, the application provides a construction method of extended semaphore under Linux environment, which comprises:

[0064] Multiplexing XSI semaphore in Linux operating system, extending flag parameter of XSI semaphore, and setting flag parameter to true to form extended semaphore;

[0065] Wherein, the extended semaphore sets task processing mode attribute and multiple interfaces on the basis of XSI semaphore;

[0066] The task processing mode attribute represents that the extended semaphore accepts task access according to task priority;

[0067] The interfaces include setting lower limit value interface, setting upper limit value interface, task waiting confirmation interface, preemption interface, task priority acquisition interface, and operation part success interface;

[0068] Wherein:

[0069] The lower limit value interface is an interface for receiving user setting of lower limit value of the extended semaphore;

[0070] The setting upper limit value interface is an interface for receiving user setting of upper limit value of the extended semaphore;

[0071] The task waiting confirmation interface is an interface for determining whether the task enters waiting state by Linux operating system when the task accessing the extended semaphore exists the condition of possibly waiting for the extended semaphore;

[0072] The preemption interface is an interface for stopping the task with lower priority and accessing the extended semaphore when the task accessing the extended semaphore must wait for the extended semaphore;

[0073] The task priority acquisition interface is an interface for acquiring priority of the task waiting for the extended semaphore; the task accessing the extended semaphore expects to perform 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 part success interface makes the task perform partial expected number of operations on the extended semaphore, and returns the value of the performed partial expected number.

[0074] In the present application, for example, the lower limit value interface sets the lower limit value of the extended semaphore to 0, the expected number of a certain task is to reduce the value of the extended semaphore by 5, but at this time the actual value of the extended semaphore is 3, then the operation part success interface makes the task only reduce the value of the extended semaphore by 3, that is, the partial expected number is 3, so that the task only performs the partial expected number of access to the extended semaphore, and returns the value of the executed partial expected number. By setting the lower limit value interface, the upper limit value interface and the operation part success interface, the maximum number of extended semaphores can be applied atomically and the blocking can be avoided as much as possible.

[0075] Further, the tasks waiting for access to the new semaphore are stored in a waiting queue, and each task corresponds to a priority, and the waiting queue is a priority queue.

[0076] The interface for determining whether the task enters the waiting state by the Linux operating system, wherein:

[0077] The Linux operating system determines whether the task enters the waiting state based on the current operating system task running condition or the priority of the task.

[0078] The implementation of stopping the operation of the task with a priority lower than the task and accessing the extended semaphore includes:

[0079] The specific number of the extended semaphore operated by each task is recorded;

[0080] The task sends a signal to the task with a priority lower than the task and accessing the extended semaphore, so that the task accessing the extended semaphore releases the semaphore.

[0081] In the present application, the priority linked list is used to record the specific number of the extended semaphore operated by each task. The priority value of the task can be obtained from the parameter of the task priority obtaining interface, and if the parameter is empty, the default is the scheduling priority of the task. If the current task performs an operation of adding a certain value to a certain 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.

[0082] In the present application, the waiting queue is a priority waiting queue, which can preferentially meet the tasks with high priority. It can also not be in the first-in first-out manner, so that in the waiting queue with the same priority, the operation is performed in the order of the small to large number of applied extended semaphores. The extended semaphore supports the preemption of the task with high priority to the task with low priority, and can make the task with low priority voluntarily give up the extended semaphore, so as to preferentially meet the task with high priority, and the task with low priority is preempted in the order of the large to small number of applied extended semaphores with the same priority.

[0083] Further, when the current task performs the decrement expected number operation on the extended semaphore, the method comprises the following steps:

[0084] Step S101: A user state constructs an access parameter request based on a current task to perform a decrement expected number operation on an extended semaphore, and calls a system call interface of a Linux operating system to enter a kernel state;

[0085] Step S102: A difference between a current value of the extended semaphore and a lower limit value is determined, and if the difference is less than the expected number, step S103 is entered; otherwise, step S107 is entered;

[0086] Step S103: Whether the current task expects to call an operation partial success interface is determined based on the access parameter; if not, step S104 is entered; if yes, and the operation partial success interface is successfully called, step S107 is entered;

[0087] Step S104: When a non-waiting identifier is set in the access parameter, an error code is returned, and the method ends;

[0088] When the non-waiting identifier is not set in the access parameter, an interface of a Linux operating system kernel is called to determine whether the current task can enter a 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;

[0089] Step S105: Whether the current task sets a parameter required by a preemption interface of the extended semaphore is determined based on the access parameter;

[0090] If not, step S106 is entered;

[0091] If yes, a preemption signal is sent to other tasks with a priority lower than that of the current task for accessing the extended semaphore, and when the preemption is not successful, step S106 is entered; when the preemption is successful, the preemption is waited for to be completed, and step S106 is entered;

[0092] Step S106: The current task enters a waiting queue corresponding to the current task, and when an operation condition of the access parameter is met, the current task is woken up;

[0093] Step S107: Whether the current task can wake up other blocked tasks is checked, if yes, the blocked tasks are woken up in a priority from high to low and in an order of application of the extended semaphore from small to large with the same priority, and step S108 is entered; if not, step S108 is entered;

[0094] Step S108: The current task is added to a priority list of tasks that have applied for the extended semaphore;

[0095] Step S109: The current task operates the extended semaphore, and returns the operation result to the user space; and returns 0 to the user space.

[0096] In the present application, the purpose of returning 0 to the user space is to tell the task of the user space that the semaphore operation is successful. In step S105, when the preemption is successful, in the case of entering step S106, the time for waiting for the operation condition of the semaphore required in the access parameter is very short, only the time for releasing the semaphore by other tasks, which is much shorter than the waiting time in other cases.

[0097] Further, when the current task performs the add-expected-number operation on the extended semaphore, the following steps are included:

[0098] Step S201: The user space constructs an access parameter based on the current task to request performing the add-expected-number operation on the extended semaphore, and calls the system call interface of the Linux operating system to enter the kernel mode;

[0099] Step S202: The difference between the current value and the upper limit value of the extended semaphore is determined, if the difference is less than the expected number, step S203 is entered; otherwise, step S205 is entered;

[0100] Step S203: When the non-waiting identifier is set in the access parameter, an error code is returned, and the method ends;

[0101] When the non-waiting identifier is not set in the access parameter, the 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;

[0102] Step S204: The current task enters the waiting queue corresponding to the current task, and when the operation condition of the semaphore required in the access parameter is met, the current task is woken up;

[0103] Step S205: It is checked whether the current task can wake up other blocked tasks, if yes, the blocked tasks are woken up in the order of high to low priority and small to large in the same priority according to the application of the extended semaphore, step S206 is entered; if no, step S206 is entered;

[0104] Step S206: If the extended semaphore held by the current task becomes 0, the current task is deleted from the priority list of the tasks which have applied for the extended semaphore, and the method ends; otherwise, step S207 is entered;

[0105] Step S207: The current task operates the extended semaphore, and returns the operation result to the user space; and returns 0 to the user space.

[0106] Further, the process of waiting for the specific value of the extended semaphore to be 0 is as follows:

[0107] Step S301: the user state constructs an access parameter request to perform an operation on the extended semaphore based on the current task, and calls a system call interface of the Linux operating system to enter the kernel state;

[0108] Step S302: when the value of the extended semaphore is 0, 0 is returned to the user space, and the method ends; otherwise, step S303 is entered;

[0109] 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 is woken up by other tasks; 0 is returned to the user space.

[0110] In the present application, the Linux operating system kernel provides an interface to facilitate manual modification of the judgment function of whether the current task can wait. For other query interfaces, only functional adaptation is performed, and no functional modification is performed.

[0111] The following describes the device for executing the device provided by the present application, and the specific implementation process and technical effects are described above, and the following will not be described again.

[0112] Optionally, the present application provides a construction device of an extended semaphore in a Linux environment, which is used in the method described above, and the device comprises:

[0113] An extension module is 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.

[0114] The extended semaphore sets the task processing mode attribute and a plurality of interfaces on the basis of the XSI semaphore.

[0115] The modules above can be one or more integrated circuits configured to implement the methods above, 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. For another example, when a certain module above is implemented in the form of a processing element scheduling program code, the processing element can be a general purpose processor, such as a Central Processing Unit (CPU) or other processor that can invoke program code. For another example, the modules can be integrated together to be implemented in the form of a system-on-a-chip (SOC).

[0116] The modules above can be connected or communicate with each other via wired or wireless connections. The wired connections can include metal cables, optical cables, hybrid cables, etc., or any combination thereof. The wireless connections can include connections in the form of LAN, WAN, Bluetooth, ZigBee, or NFC, etc., or any combination thereof. Two or more modules can be combined into a single module, and any one module can be divided into two or more units. It can be clearly understood by those skilled in the art that, for the convenience and brevity of description, the specific working processes of the system and device described above can refer to the corresponding processes in the method embodiments, which will not be repeated herein.

[0117] It should be noted that the modules above can be one or more integrated circuits configured to implement the methods above, 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. For another example, when a certain module above is implemented in the form of a processing element scheduling program code, the processing element can be a general purpose processor, such as a Central Processing Unit (CPU) or other processor that can invoke program code. For another example, the modules can be integrated together to be implemented in the form of a system-on-a-chip (SOC).

[0118] The electronic device includes a processor, a memory, a communication interface, a display screen and an input device connected through a system bus. The processor of the electronic device is configured 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 a computer program. The internal memory provides an environment for running the operating system and the computer program in the non-volatile storage medium. The communication interface of the electronic device is configured to perform wired or wireless communication with an external terminal. The wireless communication 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 overlaid on the display screen, or a button, trackball or touchpad arranged on the housing of the electronic device, or an external keyboard, touchpad or mouse.

[0119] The application further provides a program product, such as a computer readable storage medium, comprising a program configured to perform the above method embodiments when executed by a processor.

[0120] In several embodiments provided by the application, it should be understood that the disclosed apparatus and method can be implemented in other manners. For example, the described embodiments of the apparatus are merely schematic, and the division of the units is merely logical function division, and there can be another division manner in actual implementation, for example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between different units, can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical, mechanical or in other forms.

[0121] The units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the embodiments.

[0122] In addition, each functional unit in the various embodiments of the application can be integrated into one processing unit, or each unit can exist physically, or two or more units can be integrated into one unit. The integrated unit can be implemented in the form of hardware, or in the form of hardware plus software function units.

[0123] The integrated unit in the form of software function unit can be stored in a computer readable storage medium. The software function unit is stored in a storage medium, and includes a plurality of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute part of steps of the method according to various embodiments of the present application. The storage medium includes a U disk, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk, and various storage medium capable of storing program codes.

Claims

1. A method for constructing an extended semaphore in a Linux environment, characterized by, The method comprises: The XSI semaphore in the Linux operating system is multiplexed, the flag parameter of the XSI semaphore is extended, and the flag parameter is set to true to form an extended semaphore; The extended semaphore sets a task processing mode attribute and multiple interfaces on the basis of the XSI semaphore; The task processing mode attribute indicates that the extended semaphore accepts task access according to 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; The lower limit value setting interface is an interface for receiving user setting of a lower limit value of the extended semaphore; The upper limit value setting interface is an interface for receiving user setting of an upper limit value of the extended semaphore; The task waiting confirmation interface is an interface for determining, by the Linux operating system, whether a task accessing the extended semaphore enters a waiting state when the task exists in a possible waiting state of the extended semaphore; The preemption interface is an interface for stopping operation of a task with a priority lower than that of the task and accessing the extended semaphore when the task must wait for the extended semaphore; The task priority acquisition interface is an interface for acquiring a priority of a task waiting for the extended semaphore; the operation partial success interface is an interface for enabling the task to perform partial expected number of operations on the extended semaphore and returning a value of the partial expected number of operations when an updated extended semaphore is lower than the lower limit value after the task expects to perform the expected number of operations on the extended semaphore. Tasks waiting to access the newly added semaphore are stored in a waiting queue, and each task corresponds to a priority. The waiting queue is a priority queue.

2. The method of claim 1, wherein, The interface for determining, by the Linux operating system, whether the task enters the waiting state, wherein:

3. The method of claim 1, wherein, The Linux operating system determines whether the task enters the waiting state based on a current operating system task running state or the priority of the task. The manner of stopping operation of the task with the priority lower than that of the task and accessing the extended semaphore includes:

4. The method of claim 1, wherein, Recording specific numbers of operations of the tasks on the extended semaphore; Sending a signal from the task to the task with the priority lower than that of the task and accessing the extended semaphore to enable the task accessing the extended semaphore to release the semaphore. When the current task performs the expected number of operations on the extended semaphore, the method comprises the following steps:

5. The method of claim 4, wherein, Step S101: A user state constructs an access parameter request based on a current task to perform the expected number of operations on the extended semaphore, and calls a system call interface of the Linux operating system to enter a kernel state; Step S102: A difference between a current value of the extended semaphore and the lower limit value is determined. If the difference is less than the expected number, step S103 is entered; otherwise, step S107 is entered; Step S103: Whether the current task expects to call the operation partial success interface is determined based on the access parameter. If not, step S104 is entered. If yes, and the operation partial success interface is successfully called, step S107 is entered; Step S104: When an identifier indicating no waiting is set in the access parameter, an error code is returned, and the method ends; ​ When the non-waiting identifier 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 a waiting state, and 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: determining whether the current task has set the parameters required by the preemption interface of the extended semaphore based on the access parameter; If not, step S106 is entered; If yes, sending a preemption signal to other tasks with a priority lower than that of the current task accessing the extended semaphore, and when preemption fails, step S106 is entered; when preemption succeeds, waiting for preemption to complete, and then entering step S106; Step S106: the current task enters a waiting queue corresponding to the current task, and when an operation condition of the semaphore required in the access parameter is met, the current task is woken up; Step S107: checking whether the current task can wake up other blocked tasks, and if yes, waking up the blocked tasks in order of priority from high to low and in order of application of the extended semaphore from small to large with the same priority, and then entering step S108; if not, step S108 is entered; Step S108: adding the current task to a priority list of tasks that have applied for the extended semaphore; Step S109: the current task performs an operation on the extended semaphore, and returns an operation result to the user space; and returning 0 to the user space.

6. The method of claim 4, wherein, When the current task performs an operation of adding an expected number on the extended semaphore, the following steps are included: Step S201: the user space constructs an access parameter based on the current task to request an operation of adding an expected number on the extended semaphore, and calls a system call interface of the Linux operating system to enter a kernel state; Step S202: determining a difference between a current value and an upper limit value of the extended semaphore, and if the difference is less than the expected number, step S203 is entered; otherwise, step S205 is entered; Step S203: when a non-waiting identifier is set in the access parameter, an error code is returned, and the method ends; When the non-waiting identifier 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 a waiting state, and 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 a waiting queue corresponding to the current task, and when an operation condition of the semaphore required in the access parameter is met, the current task is woken up; Step S205: checking whether the current task can wake up other blocked tasks, and if yes, waking up the blocked tasks in order of priority from high to low and in order of application of the extended semaphore from small to large with the same priority, and then entering step S206; if not, step S206 is entered; Step S206: if the extended semaphore held by the current task becomes 0, the current task is deleted from a priority list of tasks that have applied for the extended semaphore, and the method ends; otherwise, step S207 is entered; Step S207: the current task performs an operation on the extended semaphore, and returns an operation result to the user space; and returning 0 to the user space.

7. A building means of extended semaphores in Linux environment, according to the method of any one of claims 1-6, characterized by, The apparatus includes: The expansion module is configured to multiplex the XSI semaphore in the Linux operating system, expand a flag parameter of the XSI semaphore, and set the flag parameter to true to form an expansion semaphore. The expansion semaphore sets a task processing mode attribute and multiple interfaces on the basis of the XSI semaphore.

8. An electronic device, comprising: The device comprises: at least one processor; and a memory connected to the at least one processor in communication; 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 perform the method of any one of claims 1-6.

9. A non-transitory computer-readable storage medium having stored thereon computer instructions, wherein, The computer instructions are used to enable the computer to perform the method of any one of claims 1-6.

Images