Task execution method, device, computer equipment, storage medium and program product

Abstract

The present application relates to a task execution method, device, computer equipment, storage medium and program product. The method includes: when a first task runs to a blocking point, after backing up the relevant data of the first task to a preset storage space, suspending the first task; wherein the preset storage space is a storage resource outside the shared stack resource pool; when the first task is awakened, the relevant data of the first task in the preset storage space is written into the first stack memory, and the first task is executed based on the first stack memory; the first stack memory is obtained from the shared stack resource pool when the first task is awakened. This method can be used to solve the problem of shared stack memory overwriting caused by task preemption when the shared stack memory is used.

Description

Technical Field

[0001] The present application relates to the field of operating system technology, and in particular to a task execution method, apparatus, computer equipment, storage medium and program product. Background Art

[0002] OSEK, the automotive electronics open system, divides tasks into two categories based on their execution characteristics: basic tasks (BTs) and extended tasks (ETs). BTs do not have a waiting state and will continue to execute once they start, while ETs can use interfaces that cause task suspension. Therefore, for ETs, since they involve task suspension during task execution, stack memory backup must be performed when task context is switched.

[0003] Generally, for ETs stack memory sharing, currently the main method is to set up a shared stack (the stack where BTs is located) and a private stack (exclusive to each ETs), and modify the ETs task stack to execute part of the ETs work in the BTs stack, so as to achieve the sharing of the two task stack memories. Currently, the task priority preemption mechanism is used for the use of shared stack memory. However, the traditional method of using shared stack memory has the problem of shared stack memory being overwritten due to task preemption. Summary of the invention

[0004] The embodiments of the present application provide a task execution method, apparatus, computer device, storage medium and program product, which can be used to solve the problem of shared stack memory overwriting caused by task preemption when the shared stack memory is used.

[0005] In a first aspect, an embodiment of the present application provides a task execution method, including:

[0006] When the first task runs to a blocking point, after backing up the relevant data of the first task to a preset storage space, the first task is suspended; wherein the preset storage space is a storage resource outside the shared stack resource pool;

[0007] When the first task is awakened, the relevant data of the first task in the preset storage space is written into the first stack memory, and the first task is executed based on the first stack memory; the first stack memory is obtained from the shared stack resource pool when the first task is awakened.

[0008] In a second aspect, an embodiment of the present application provides a task execution device, including:

[0009] A backup module, used for suspending the first task after backing up the relevant data of the first task to a preset storage space when the first task runs to a blocking point; wherein the preset storage space is a storage resource outside the shared stack resource pool;

[0010] The first execution module is used to write the relevant data of the first task in the preset storage space into the first stack memory when the first task is awakened, and execute the first task based on the first stack memory; the first stack memory is obtained from the shared stack resource pool when the first task is awakened.

[0011] In a third aspect, an embodiment of the present application provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the task execution method described in the first aspect.

[0012] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the task execution method described in the first aspect are implemented.

[0013] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program, which, when executed by a processor, implements the steps of the task execution method described in the first aspect.

[0014] The above-mentioned task execution method, device, computer equipment, storage medium and program product, when the first task runs to a blocking point, after backing up the relevant data of the first task to a preset storage space, suspends the first task, and when the first task is awakened, writes the relevant data of the first task in the preset storage space into the first stack memory, and executes the first task based on the first stack memory. Since the preset storage space in this process is a storage resource outside the shared stack resource pool, the relevant data of the first task is backed up outside the shared stack resource pool when the first task is suspended, so that after other tasks preempt the stack memory of the first task, the data in the stack memory of the first task will not be overwritten. In addition, when the first task is awakened, since the first stack memory is obtained from the shared stack resource pool, the relevant data of the first task in the preset storage space is written into the first stack memory, so that when the first task is awakened, the first task occupies the stack memory of other tasks to execute the first task, which avoids the situation that different tasks preempt the same stack memory, and solves the problem of data being overwritten in the shared stack due to task preemption. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.

[0016] Figure 1 An application environment diagram of a task execution method in an embodiment;

[0017] Figure 2 A schematic diagram of a function call relationship diagram in one embodiment;

[0018] Figure 3 A schematic diagram of task switching when executing tasks T1 and T2 in one embodiment;

[0019] Figure 4 A schematic diagram of task execution without SETs stack memory in one embodiment;

[0020] Figure 5 A schematic diagram of task execution with SETs stack memory in one embodiment;

[0021] Figure 6 is a schematic diagram of a stack in an embodiment;

[0022] Figure 7 is a flowchart of a task execution method in one embodiment;

[0023] Figure 8 A schematic diagram of the calling hierarchy of tasks in one embodiment;

[0024] Fig. 9 is a flowchart of a task execution method in another embodiment;

[0025] Fig.10 is a flowchart of a task execution method in another embodiment;

[0026] Fig.11 FIG. 4 is a structural block diagram of a task execution device in an embodiment. DETAILED DESCRIPTION

[0027] In order to make the purpose, technical solution and advantages of the present application more clearly understood, the present application is further described in detail below in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0028] The task execution method provided in the embodiment of the present application can be applied to Figure 1In the application environment shown. Among them, the computer device includes a processor and a memory connected by a system bus, and a computer program is stored in the memory. When the processor executes the computer program, the steps of the following method embodiment can be executed. Optionally, the computer device may also include a network interface, a display screen and an input device. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory, and the non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal through a network connection. Optionally, the computer device can be a server, a personal computer, a personal digital assistant, or other terminal devices, such as a tablet computer, a mobile phone, etc., or a cloud or remote server. The embodiment of the present application does not limit the specific form of the computer device.

[0029] Those skilled in the art will understand that Figure 1 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have a different arrangement of components.

[0030] In traditional technology, for ETs stack memory sharing, the main method is to set up a shared stack (the stack where BTs are located) and a private stack (exclusive to each ETs). By modifying the ETs task stack needle, part of the ETs work is executed in the BTs stack, so as to achieve the sharing of the two task stack memories. Such ETs are usually named SETs (semi-extended tasks). SETs are essentially ETs. SETs have their own independent stacks. On this private stack, blocking systems such as messages and semaphores can be called. However, for some functions in SETs that do not have blocking interface calls, SETs can cut the stack to the stack where BTs are located, that is, the shared stack. The function that triggers the stack switch is called the switching function. If the entry function of a semi-extended task SETs is a switching function, then this semi-extended task SETs is completely executed as BTs. Conversely, if the semi-extended task SETs does not have any switching function, then this semi-extended task SETs is executed as ETs.

[0031] For example, Figure 2 and Figure 3 As shown, Figure 2 , Figure 3 In the above, T1 and T2 both represent tasks, e1 represents the entry function of task T1, e2 represents the entry function of task T2, f represents the calling function, and S represents the blocking function. Figure 2It is the function call graph (Call Graph), such as Figure 2 As shown in , when both T1 and T2 run to the blocking function, the calling function f will be run. Figure 3 As shown in FIG. 1 , it is a schematic diagram of task switching when executing tasks T1 and T2. For example, task T1 activates task T2 during execution, and returns to execute task T1 after task T2 is completed. Figure 4 and Figure 5 As shown in Figure 2, the memory usage of SETs stack is compared with that of normal BTs / ETs stack, where Figure 4 and Figure 5 Each small box in the table represents that it occupies 10 bytes. It should be noted that Figure 4 and Figure 5 The box where e1 is located means that it occupies 10 bytes, the box where f1 is located means that it occupies 2 small boxes, f1 occupies 20 bytes, the box where S is located means that it occupies 5 small boxes, S occupies 50 bytes, Figure 4 The example shows the situation without SETs. T1 and T2 both have independent stacks, each stack occupies 60 bytes, and the total occupies 120 bytes. After using SETs, f1(), f2(), and S() do not trigger blocking and can be switched to the shared stack for execution. Figure 5 As shown, after using SETs, the shared stack occupies a maximum of 50 bytes. The private stacks of T1 and T2 are smaller, each occupying 10 bytes. The total stack used by this model occupies 70 bytes.

[0032] Generally, the implementation of the above switching function is not complicated. During the task execution process, each function call has a call frame on the stack, which contains the parameters passed by the call, local variables and return address. The call frame is addressed by the stack pointer esp and the base pointer ebp in the register. The esp pointer points to the end of the stack layer, and the subfunction uses it as the starting point to store the call frame; the ebp pointer points to the return address and parameter block, which is used to access the parameters. In order to implement the switching function, by restricting the access mode adopted by the compiler, local variables are accessed through the esp pointer, and parameters are accessed through the ebp pointer. By separating the access paths of local variables and parameters, parameters and local variables are placed in different memory locations, that is, parameters are placed in the private stack and local variables are placed in the shared stack. In addition, in order to perform the actual stack needle switching, the compiler is used to add an instruction at the entry of the task switching function to set the esp pointer to the top of the shared stack, thereby realizing the switching of the task context.

[0033] For example, take the execution process of the f1() function as an example. When f1() enters, the original stack pointer is stored in %ebp, and %esp is modified to point to the shared stack memory address (TOS_BTS). The execution of the function body inside the f1 function is all executed in the shared stack. When the function returns, the standard function return operation restores %esp through %ebp, and when exiting, it returns to the private stack for execution. Figure 6 As shown, Figure 6 The stack diagram shows the situation where SETs preempts BTs and switches to the shared stack with f1(). After SETs preempts BTs, it starts to execute tasks from the entry function e2. When calling function f1, it pushes arg2 and arg1 on the stack in sequence at the function entry, returns the address old ebp to SETs' private stack, and assigns the current esp to ebp (ebp stores the sp of the private stack at this time. It is necessary to ensure that ebp is no longer used to query local variables during the execution of f1. This can be achieved by modifying the compiler). Then TOS_BTS assigns esp, and SETs' stack is now switched to the shared stack of BTs. Then bar is called in the shared stack, and the required variables are pushed into the shared stack through esp (local1-local4), and then bar is executed. When exiting and returning, the value of the private stack stored in ebp is directly assigned to esp, and the shared stack is switched back to the shared stack, and the parameters previously stored in the private stack are popped out.

[0034] However, the above solution will cause the shared stack content to be overwritten due to task preemption. Suppose task T1 is executing on the shared stack, and an external interrupt arrives to trigger task T2 with a higher priority than task T1. Task T2 will preempt the shared stack of task T1. Since all switching functions use TOS_BTS as the start of the stack frame, the shared stack will be overwritten.

[0035] With respect to the above-mentioned method of using shared stack memory, there is a problem of shared stack memory overwriting due to task preemption. The embodiment of the present application proposes a task execution method, apparatus, computer equipment, storage medium and program product to solve the problem of shared stack memory overwriting due to task preemption when using shared stack memory.

[0036] In one embodiment, Figure 7 As shown, a task execution method is provided, which is applied to Figure 1 The computer device in the example is used to illustrate, including the following steps:

[0037] S201, when the first task runs to a blocking point, after backing up the relevant data of the first task to a preset storage space, suspending the first task; wherein the preset storage space is a storage resource outside the shared stack resource pool.

[0038] First of all, it should be noted that the application scenario of the embodiment of the present application can be a multi-core preemptive embedded system based on priority scheduling, and can also be applied to a single-core scenario, where the entry functions of different tasks are consistent and the triggering methods are consistent. The following is an example of an application system where the CPU has 4 cores and the triggering methods are all message triggering.

[0039] Among them, the blocking point refers to the point where the task can no longer be executed after running to this point. For example, when the task runs to a certain point, it will wait for receiving messages or wait for receiving events. The point where it waits for receiving messages or events can be called a blocking point.

[0040] It should be noted that the application scenarios of the embodiments of the present application can be generalized and are not limited to message receiving and sending tasks. The task execution methods provided by the embodiments of the present application can be used for all scenarios with multiple tasks blocked on a certain resource. For example, the task execution methods provided by the embodiments of the present application can be used for multiple tasks blocked on semaphores, events, etc.

[0041] Optionally, in order to avoid the high-priority task preempting the low-priority task and causing the task stack to be overwritten, in the embodiment of the present application, a stack memory is provided separately for each priority task, and tasks of different priorities correspond to different stack memories. Optionally, different tasks can determine the corresponding stack memory from the shared stack resource pool according to their own priorities.

[0042] In a multi-core scenario, in order to reduce the extra overhead caused by multi-core preemption, a shared stack resource pool can be set up for each core. Then, for the first task mentioned above, the shared stack resource pool is the shared stack resource pool corresponding to the core where the first task is located. Optionally, the shared stack resource pool can include multiple stack memories. For the allocation of stack memory, the block algorithm can be used to allocate the memory in the shared resource pool in blocks of 2KB to obtain multiple stack memories included in the shared resource pool.

[0043] In addition, in order to avoid the high-priority task preempting the low-priority task and causing the task stack to be overwritten, for the stack memory of the same-priority task, each task can back up the data related to itself to the storage resources other than the shared stack resource pool, such as the static heap, or other storage resources other than the shared stack resource pool, etc. That is to say, the preset storage space in this embodiment can be a static heap, or other storage resources other than the shared stack resource pool. Optionally, the relevant data of the first task may include the register configuration of the first task, the offset value of the task stack frame of the first task, and the local variables of the first task, etc., which are not limited in the embodiments of the present application.

[0044] S202, when the first task is awakened, write the relevant data of the first task in the preset storage space into the first stack memory, and execute the first task based on the first stack memory; the first stack memory is obtained from the shared stack resource pool when the first task is awakened.

[0045] Among them, the above-mentioned first stack memory is obtained from the above-mentioned shared stack resource pool when the first task is awakened. Optionally, the above-mentioned shared stack resource pool is the shared stack resource pool corresponding to the core where the first task is located. That is to say, the above-mentioned first stack memory is determined from the shared stack resource pool corresponding to the core where the first task is located when the first task is awakened.

[0046] Optionally, the first stack memory may be applied for the first task from the shared stack resource pool by other tasks that wake up the first task, or may be applied for the first task from the shared stack resource pool by other running tasks. In this embodiment, when the first task is awakened, after obtaining the first stack memory from the shared stack resource pool, the first stack memory may read the relevant data of the first task from the preset storage space, and write the relevant data of the first task into the first stack memory corresponding to the first task, and then the computer device may execute the first task based on the first stack memory into which the relevant data of the first task is written.

[0047] In the above-mentioned task execution method, when the first task runs to a blocking point, the relevant data of the first task is backed up to a preset storage space, and then the first task is suspended. When the first task is awakened, the relevant data of the first task in the preset storage space is written into the first stack memory, and the first task is executed based on the first stack memory. Since the preset storage space in this process is a storage resource outside the shared stack resource pool, the relevant data of the first task is backed up outside the shared stack resource pool when the first task is suspended, so that after other tasks preempt the stack memory of the first task, the data in the stack memory of the first task will not be overwritten. In addition, when the first task is awakened, since the first stack memory is obtained from the shared stack resource pool, the relevant data of the first task in the preset storage space is written into the first stack memory. This avoids the situation where the first task occupies the stack memory of other tasks to execute the first task when the first task is awakened, avoids different tasks preempting the same stack memory, and solves the problem of data being overwritten in the shared stack due to task preemption.

[0048] Further, in one embodiment, the above-mentioned relevant data includes at least one of the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value of the first task in the second stack memory, the return address value, the encapsulated thread local variable of the first task and the received message local variable of the first task; wherein the second stack memory is a stack memory determined from the shared stack resource pool before the first task is created for storing relevant data. The reasons for backing up these data are described in detail below:

[0049] a. When the entry functions of different tasks are consistent, the register configuration of each task is consistent when performing context switching. Therefore, the register configuration of the task can be backed up. It should be noted that the configuration of the saved register S0 needs to be calculated at runtime and then backed up.

[0050] b. When performing a task context switch, the offset of the position pointed to by each task stack frame relative to the bottom of the stack is fixed, so the offset value of each task stack frame can be backed up.

[0051] c. Before the task is executed to the blocking point, it will go through several layers of call layers. Each layer of call will store the value of the save register S0 and the value of the return address ra on the stack. Since the calling function is consistent, the value of the return address ra of each layer of call is fixed, and the offset value of the save register S0 relative to the bottom of the stack is also fixed. Therefore, the save register offset value and return address value of the first task in the second stack memory can be backed up. Among them, the second stack memory is a stack memory for storing the above-mentioned related data determined from the shared stack resource pool before the first task is created. Optionally, in this embodiment, the second stack memory can be determined from the shared stack resource pool according to the priority of the first task before the first task is created. It can be understood that in a multi-core scenario, a shared stack resource pool is set separately for each core. Then, for the above-mentioned first task, the above-mentioned shared stack resource pool is the shared stack resource pool corresponding to the core where the first task is located, that is, the above-mentioned second stack memory is determined from the shared stack resource pool corresponding to the core where the first task is located according to the priority of the first task. Continuing with the example of the entry function of the above message receiving task, when the task executes to the 6th line message queue - receiving message tx_queue_receive until the context switch, it will go through 4 layers of calls. The schematic diagram of these four layers of call levels is as follows Figure 8 As shown, each of the four layers of calls will store the value of the save register S0 and the value of the return address ra on the stack. Since the calling functions are consistent, the value of ra in each of the four layers is fixed, and the offset of the save register S0 relative to the bottom of the stack is fixed. Therefore, the save register offset value and return address value of the stack memory of the message task can be backed up.

[0052] d. When returning from the system suspension interface in the message queue-receiving message tx_queue_receive, it is necessary to use a local variable to encapsulate the value of the thread thread_ptr. Since the value of the encapsulated thread thread_ptr local variable of each task is not fixed, the encapsulated thread thread_ptr local variable can be backed up.

[0053] e. In the thread_entry of the entry function of each task, the only local variable that needs attention is the received message received_msg local variable. This value will be stored in the stack as an output parameter, but the writing of this value data is obtained when sending a task or sending a message. Therefore, directly using the address of the local variable to pass in will cause execution exceptions. For example, if another task with the same priority is executing, the message sent will be directly written into the shared stack, and operation exceptions may occur due to the overwriting of values. Therefore, the receive message receive_msg local variable needs to be backed up.

[0054] Further, the preset storage space includes a system control block and a preset memory, and the step of “backing up the relevant data of the first task to the preset storage space” in S201 includes at least one of the following:

[0055] The first item backs up at least one of the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value of the first task in the second stack memory, and the return address value to the preset memory.

[0056] In this embodiment, the preset storage space includes a preset memory, and the preset memory may be a storage resource outside the shared stack resource pool, for example, a static heap or the like.

[0057] Furthermore, since the register configurations of each task are consistent, the computer device can globally preset a block of memory, such as a static heap, and back up the register configurations of each task in the memory.

[0058] When each task performs context switching, the offset of the position pointed to by each task stack frame relative to the bottom of the stack is fixed, so the offset value of each task stack frame can be stored globally, and the offset value of each task stack frame is related to the register configuration of each task, so the offset value of each task stack frame can be backed up in the above-mentioned preset memory;

[0059] Since the calling functions of each task are consistent, the return address value of each calling layer is fixed, and the offset of the save register S0 of each task stack memory relative to the bottom of the stack is fixed. Therefore, the save register offset value of each task's stack memory and the return address value of each task can also be stored globally. In other words, the save register offset value of each task's stack memory and the return address value of each task can also be backed up in the above-mentioned preset memory.

[0060] The second item is to back up the encapsulated thread local variables of the first task and / or the received message local variables of the first task to the system control block.

[0061] In this embodiment, the above-mentioned preset storage space includes a system control block, which is related to the operating system, and the encapsulated thread thread_ptr local variable of each task and the received message receive_msg local variable of each task are also related to the operating system. Therefore, the encapsulated thread thread_ptr local variable of each task and / or the received message receive_msg local variable of each task can be stored in the system control block of the operating system. Then, for the first task, the encapsulated thread thread_ptr local variable of the first task and / or the received message receive_msg local variable of the first task can be backed up to the system control block in the preset storage space.

[0062] Further, as an optional implementation, the task control block structure of the real-time operating system RTOS may be modified to back up the encapsulated thread thread_ptr local variable of each task and / or the received message receive_msg local variable of each task to the system control block.

[0063] In addition, it should be noted that since the address of the system control block of each task is unique, the encapsulated thread thread_ptr local variable of each task and / or the received message receive_msg local variable of each task are backed up in the system control block, and the system control blocks of each task will not overwrite each other.

[0064] Furthermore, taking the application scenario of the task execution method provided by the present application as an example, all tasks have independent stack memory, there are 44 tasks in total, each task uses 2KB of stack memory, and a total of 88KB of stack memory is used as an example, after a large number of experiments, the beneficial effects of using the task execution method provided by the present application are as follows:

[0065] Under the task execution method provided in this application, the stack memory usage depends on the number of priorities used by each core. Under the maximum specification, core 0 has 10 priorities, and cores 1 to 3 each have 4 priorities. The final memory usage is calculated as follows:

[0066] 1. The stack memory resource pool usage is 44KB.

[0067] 2. The task control block of each task requires an additional 8 bytes to store local variables and received messages, and the memory occupies 352 bytes.

[0068] 3. The global storage context switch register backup data memory occupies 64 bytes.

[0069] 4. The global storage stack pointer sp occupies 4 bytes of memory offset from the bottom of the stack.

[0070] 5. The s0 offset and return address memory required for the 4-level call stack stored globally take up 32 bytes.

[0071] The total memory used is 45508 bytes, which is 49.4% less than the memory used without optimization.

[0072] From the description of the above experimental data, it can be seen that the task execution method provided by the present application merges the stacks of tasks of the same priority to a certain extent with little impact on system performance, helping to solve the problem of memory shortage in embedded systems.

[0073] In this embodiment, the relevant data of the first task includes the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value of the first task in the second stack memory, the return address value, the encapsulated thread local variables of the first task and at least one of the received message local variables of the first task. By backing up at least one of the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value of the first task in the second stack memory and the return address value to the preset memory, and backing up the encapsulated thread local variables of the first task and / or the received message local variables of the first task to the system control block, the relevant data of the first task can be prevented from being overwritten by the data of other tasks, thereby solving the problem of data being overwritten in the shared stack due to task preemption.

[0074] Furthermore, in the above scenario after backing up the relevant data of the first task to the preset storage space, the second stack memory can be released to make the second stack memory an empty memory. Based on the above embodiment, in one embodiment, the above method also includes: after backing up the relevant data to the preset storage space, releasing the second stack memory.

[0075] In this embodiment, since the data related to the first task is backed up to the preset storage space, the data related to the first task has backup data, and the second stack memory can be released at this time, so that the second stack memory becomes an empty memory, and the backed-up data is no longer stored. Further, as an optional implementation, the second task can be executed in the second stack memory after release, or other tasks can also be executed in the second stack memory after release, which can effectively avoid the waste of idle stack memory resources and ensure the effective use of stack memory.

[0076] In the process of backing up the relevant data of the first task to the preset storage space, in order to avoid the situation where the same stack memory is used by two tasks at the same time, in one embodiment, the method further includes: in the process of backing up the relevant data to the preset storage space, controlling the operating system to turn off the preemption function; and after releasing the second stack memory, controlling the operating system to turn on the preemption function; the preemption function means that other tasks other than the first task are allowed to preempt the second stack memory.

[0077] The preemption function means that other tasks other than the first task are allowed to preempt the second stack memory. For example, task T1 is executing tasks in its stack memory. When an external interrupt or task T2 occurs, and the priority of task T2 is higher than that of task T1, task T2 will preempt the stack memory of task T1. During the context switch, that is, during the backup of the relevant data of the first task, after the control operating system turns off the preemption function, the above task T2 will not be able to preempt the stack memory of task T1. However, when the backup of the relevant data of the first task is completed and the second stack memory is completely released, task T2 can preempt the second stack memory.

[0078] In this embodiment, in the process of backing up the relevant data of the above-mentioned first task to the preset storage space, in order to avoid other tasks except the first task from preempting the second stack memory corresponding to the first task, the operating system can be controlled to turn off the preemption function, thereby avoiding the situation where the same stack memory is used by two tasks at the same time; and after backing up the relevant data of the first task stored in the second stack memory to the preset storage space and releasing the second stack memory, since the relevant data stored in the second stack memory of the first task has been backed up at this time, the second stack memory is an empty memory after being released, and other tasks can use the released second stack memory. Therefore, after the second stack memory is released, the operating system can be controlled to turn on the above-mentioned preemption function, so that the stack memory can be used flexibly to avoid waste of resources.

[0079] To facilitate understanding by those skilled in the art, the task execution method provided by this application is described in detail below. Fig. 9 and Fig.10 ,in, Fig. 9In the example, task A represents the first task, task B represents the second task, and task A and task B are tasks of the same type. Fig. 9 As shown, Task A and Task B are message receiving tasks. First, apply for task stack memory for Task A. After Task A is created, Task A will be automatically executed. When Task A runs to a blocking point (such as a message receiving point), it will be blocked. The key data in the stack memory corresponding to Task A can be backed up, and the stack memory corresponding to Task A can be released to suspend Task A. After that, Task B can send a message to Task A to wake up Task A, apply for stack memory for Task A, restore the key data of Task A stack, schedule Task A and execute Task A, and process the received message when it is received.

[0080] like Fig.10 The complete process of the method shown may include:

[0081] S1, before creating a first task, determining a second stack memory from a shared stack resource pool corresponding to a first task core according to a priority of the first task.

[0082] S2, when the first task runs to a blocking point, backs up at least one of the register configuration of the first task stored in the second stack memory, the offset value of the task stack frame of the first task, the saved register offset value of the second stack memory, and the return address value to the preset memory; backs up the encapsulated thread local variables of the first task and / or the received message local variables of the first task to the system control block.

[0083] S3, in the process of backing up the relevant data to the preset storage space, controlling the operating system to turn off the preemption function.

[0084] S4, suspend the first task, release the second stack memory, and after releasing the second stack memory, control the operating system to enable the preemption function.

[0085] S5, executing the second task in the released second stack memory.

[0086] S6, when the first task is awakened, a corresponding first stack memory is determined for the first task from the shared stack resource pool corresponding to the core where the first task is located.

[0087] S7, writing the relevant data of the first task in the preset storage space into the first stack memory corresponding to the first task, and executing the first task based on the first stack memory.

[0088] It should be noted that for the description in the above S1-S7, reference may be made to the relevant description in the above embodiment, and the effects are similar, so this embodiment will not be repeated here.

[0089] It should be understood that, although the steps in the flowcharts involved in the above embodiments are displayed in sequence according to the indication of the arrows, these steps are not necessarily executed in sequence according to the order indicated by the arrows. Unless there is a clear explanation in this article, the execution of these steps is not strictly limited in order, and these steps can be executed in other orders. Moreover, at least a part of the steps in the flowcharts involved in the above embodiments may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times, and the execution order of these steps or stages is not necessarily carried out in sequence, but can be executed in turn or alternately with other steps or at least a part of the steps or stages in other steps.

[0090] Based on the same inventive concept, the embodiment of the present application also provides a task execution device for implementing the task execution method involved above. The implementation scheme for solving the problem provided by the device is similar to the implementation scheme recorded in the above method, so the specific limitations in one or more task execution device embodiments provided below can refer to the limitations on the task execution method above, and will not be repeated here.

[0091] In one embodiment, Fig.11 As shown, a task execution device is provided, comprising: a backup module and a first execution module, wherein:

[0092] The backup module is used to suspend the first task after backing up the relevant data of the first task to a preset storage space when the first task runs to a blocking point; wherein the preset storage space is a storage resource outside the shared stack resource pool.

[0093] The first execution module is used to write the relevant data of the first task in the preset storage space into the first stack memory when the first task is awakened, and execute the first task based on the first stack memory; the first stack memory is obtained from the shared stack resource pool when the first task is awakened.

[0094] Optionally, the above-mentioned relevant data includes the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value of the first task in the second stack memory, the return address value, the encapsulated thread local variables of the first task and at least one of the received message local variables of the first task; wherein, the second stack memory is a stack memory for storing relevant data determined from the shared stack resource pool before the first task is created.

[0095] Optionally, the second stack memory is determined from a shared stack resource pool corresponding to the core where the first task is located before the first task is created.

[0096] Optionally, the first stack memory is determined from a shared stack resource pool corresponding to the core where the first task is located when the first task is awakened.

[0097] Optionally, the shared stack resource pool includes multiple stack memories, and tasks of different priorities correspond to different stack memories.

[0098] The task execution device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0099] Based on the above embodiment, optionally, the preset storage space includes a system control block and a preset memory; the backup module includes at least one of the following first backup unit and second backup unit, wherein:

[0100] The first backup unit is used to back up at least one of the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value and the return address value of the second stack memory to the preset memory.

[0101] The second backup unit is used to back up the encapsulated thread local variables of the first task and / or the received message local variables of the first task to the system control block.

[0102] The task execution device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0103] Based on the above embodiment, optionally, the above device further includes: a determination module, wherein:

[0104] The determination module is used to determine the second stack memory from the shared stack resource pool according to the priority of the first task before the first task is created.

[0105] The task execution device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0106] Based on the above embodiment, optionally, the above device further includes: a release module, wherein:

[0107] The release module is used to release the second stack memory after backing up the relevant data to the preset storage space.

[0108] The task execution device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0109] Based on the above embodiment, optionally, the above device further includes: a second execution module, wherein:

[0110] The second execution module is used to execute the second task in the released second stack memory.

[0111] The task execution device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0112] Based on the above embodiment, optionally, the above device further includes: a control module, wherein:

[0113] The control module is used to control the operating system to turn off the preemption function during the process of backing up relevant data to the preset storage space; and, after releasing the second stack memory, control the operating system to turn on the preemption function; the preemption function means that other tasks besides the first task are allowed to preempt the second stack memory.

[0114] The task execution device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, which will not be repeated here.

[0115] Each module in the above task execution device can be implemented in whole or in part by software, hardware or a combination thereof. Each module can be embedded in or independent of a processor in a computer device in the form of hardware, or can be stored in a memory in a computer device in the form of software, so that the processor can call and execute the operations corresponding to each module.

[0116] In one embodiment, a computer device is provided, including a memory and a processor, wherein a computer program is stored in the memory, and when the processor executes the computer program, the following steps are implemented:

[0117] When the first task runs to a blocking point, after backing up the relevant data of the first task to a preset storage space, the first task is suspended; wherein the preset storage space is a storage resource outside the shared stack resource pool;

[0118] When the first task is awakened, the relevant data of the first task in the preset storage space is written into the first stack memory, and the first task is executed based on the first stack memory; the first stack memory is obtained from the shared stack resource pool when the first task is awakened.

[0119] Optionally, the above-mentioned relevant data includes the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value of the first task in the second stack memory, the return address value, the encapsulated thread local variables of the first task and at least one of the received message local variables of the first task; wherein, the second stack memory is a stack memory for storing relevant data determined from the shared stack resource pool before the first task is created.

[0120] Optionally, the second stack memory is determined from a shared stack resource pool corresponding to the core where the first task is located before the first task is created.

[0121] Optionally, the first stack memory is determined from a shared stack resource pool corresponding to the core where the first task is located when the first task is awakened.

[0122] Optionally, the shared stack resource pool includes multiple stack memories, and tasks of different priorities correspond to different stack memories.

[0123] In one embodiment, the preset storage space includes a system control block and a preset memory; when the processor executes the computer program, at least one of the following steps is also implemented:

[0124] Backing up at least one of the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value and the return address value of the second stack memory to a preset memory;

[0125] The encapsulated thread local variables of the first task and / or the received message local variables of the first task are backed up in the system control block.

[0126] In one embodiment, when the processor executes the computer program, the following steps are also implemented:

[0127] Before the first task is created, the second stack memory is determined from the shared stack resource pool according to the priority of the first task.

[0128] In one embodiment, when the processor executes the computer program, the following steps are also implemented:

[0129] After backing up the relevant data to the preset storage space, the second stack memory is released.

[0130] In one embodiment, when the processor executes the computer program, the following steps are also implemented:

[0131] The second task is executed in the second stack memory after the release.

[0132] In one embodiment, when the processor executes the computer program, the following steps are also implemented:

[0133] In the process of backing up relevant data to the preset storage space, the control operating system turns off the preemption function; and after releasing the second stack memory, the control operating system turns on the preemption function; the preemption function means that other tasks besides the first task are allowed to preempt the second stack memory.

[0134] The embodiment of the present application also provides a computer-readable storage medium, one or more non-volatile computer-readable storage media containing computer-executable instructions, which, when executed by one or more processors, enable the processors to perform the steps of the above-mentioned task execution method.

[0135] The embodiment of the present application also provides a computer program product including instructions, which, when executed on a computer, enables the computer to execute the above-mentioned task execution method.

[0136] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards of relevant countries and regions.

[0137] Those skilled in the art can understand that all or part of the processes in the above-mentioned embodiment methods can be completed by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above-mentioned methods. Among them, any reference to the memory, database or other medium used in the embodiments provided in the present application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetoresistive random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in each embodiment provided in this application may include at least one of a relational database and a non-relational database. Non-relational databases may include distributed databases based on blockchains, etc., but are not limited thereto. The processor involved in each embodiment provided in this application may be a general-purpose processor, a central processing unit, a graphics processor, a digital signal processor, a programmable logic device, a data processing logic device based on quantum computing, etc., but are not limited thereto.

[0138] The technical features of the above embodiments may be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0139] The above-described embodiments only express several implementation methods of the present application, and the descriptions thereof are relatively specific and detailed, but they cannot be understood as limiting the scope of the present application. It should be pointed out that, for a person of ordinary skill in the art, several variations and improvements can be made without departing from the concept of the present application, and these all belong to the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the attached claims.

Claims

1. A task execution method, characterized in that: include: When the first task runs to a blocking point, the relevant data of the first task is backed up to a preset storage space, and in the process of backing up the relevant data to the preset storage space, the operating system is controlled to turn off the preemption function; and after releasing the second stack memory, the operating system is controlled to turn on the preemption function, and after the relevant data is backed up to the preset storage space, the first task is suspended; wherein the preset storage space is a storage resource outside the shared stack resource pool; the second stack memory is a stack memory for storing the relevant data determined from the shared stack resource pool before the first task is created; the preemption function indicates that other tasks except the first task are allowed to preempt the second stack memory; When the first task is awakened, the relevant data of the first task in the preset storage space is written into the first stack memory, and the first task is executed based on the first stack memory; the first stack memory is obtained from the shared stack resource pool when the first task is awakened.

2. The method according to claim 1, characterized in that The relevant data includes at least one of the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value of the first task in the second stack memory, the return address value, the encapsulated thread local variables of the first task and the received message local variables of the first task.

3. The method according to claim 2, characterized in that The preset storage space includes a system control block and a preset memory; and backing up the relevant data of the first task to the preset storage space includes at least one of the following: Backing up at least one of the register configuration of the first task, the offset value of the task stack frame of the first task, the saved register offset value of the second stack memory and the return address value into the preset memory; The encapsulated thread local variables of the first task and / or the received message local variables of the first task are backed up in the system control block.

4. The method according to claim 2 or 3, characterized in that: The second stack memory is determined from the shared stack resource pool before the first task is created, and includes: The second stack memory is determined from a shared stack resource pool corresponding to the core where the first task is located before the first task is created.

5. The method according to claim 4, characterized in that The first stack memory is determined from a shared stack resource pool corresponding to the core where the first task is located when the first task is awakened.

6. The method according to claim 5, characterized in that The shared stack resource pool includes a plurality of stack memories, and tasks of different priorities correspond to different stack memories.

7. The method according to claim 6, characterized in that The method further comprises: Before the first task is created, the second stack memory is determined from the shared stack resource pool according to the priority of the first task.

8. The method according to claim 2, characterized in that: The method further comprises: After backing up the relevant data to the preset storage space, releasing the second stack memory.

9. The method according to claim 8, characterized in that The method further comprises: The second task is executed in the second stack memory after the release.

10. A task execution device, characterized in that: include: A backup module, used for backing up the relevant data of the first task to a preset storage space when the first task runs to a blocking point, and controlling the operating system to turn off the preemption function in the process of backing up the relevant data to the preset storage space; and, after releasing the second stack memory, controlling the operating system to turn on the preemption function, and suspending the first task after the relevant data is backed up to the preset storage space; wherein the preset storage space is a storage resource outside the shared stack resource pool; the second stack memory is a stack memory for storing the relevant data determined from the shared stack resource pool before the first task is created; the preemption function indicates that other tasks except the first task are allowed to preempt the second stack memory; The first execution module is used to write the relevant data of the first task in the preset storage space into the first stack memory when the first task is awakened, and execute the first task based on the first stack memory; the first stack memory is obtained from the shared stack resource pool when the first task is awakened.

11. A computer device comprising a memory and a processor, wherein a computer program is stored in the memory, wherein: When the computer program is executed by the processor, the processor is caused to perform the steps of the task execution method according to any one of claims 1 to 9.

12. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the task execution method according to any one of claims 1 to 9 are implemented.

13. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the task execution method described in any one of claims 1 to 9 are implemented.

Images