Task scheduling method and device, electronic device and computer readable storage medium

Abstract

The present application discloses a task scheduling method and device, an electronic device, and a computer-readable storage medium. The method includes: generating multiple tasks according to a received task request; assigning each task of the task request to an execution body and forming an execution body queue; using a scheduler running on a thread to call the execution body in the execution body queue to execute the task corresponding to the called execution body on the thread of the scheduler. The embodiment of the present application provides a method of assigning the split tasks to an execution body with higher flexibility, and uses a scheduler running on each thread to schedule the execution body, so that the grouping and weight setting of the execution body corresponding to the task can be realized through the scheduler on the thread, and the scheduling and switching of the execution body with higher flexibility can be performed by the scheduler bound to the thread. A balance between high concurrency and fairness is achieved.

Description

Technical Field

[0001] The present application relates to the field of task management, and in particular to a task scheduling method and device, an electronic device, and a computer-readable storage medium. Background Art

[0002] In interactive analysis products for big data, after users submit big data query requests, the query results need to be returned to the users in a timely manner. If the user's waiting time is too long, for example, more than 10 seconds, the query task will lose interactivity. Therefore, a solution is needed that can achieve a balance in concurrent task allocation and execution fairness. Summary of the invention

[0003] The embodiments of the present application provide a task scheduling method and device, an electronic device, and a computer-readable storage medium to solve the defect that task scheduling in the prior art cannot take into account both fairness and flexibility.

[0004] To achieve the above object, the present application provides a task scheduling method, including:

[0005] Generate multiple tasks according to the received task request;

[0006] Allocating each task of the task request to an execution body and forming an execution body queue, wherein the execution body and the assigned task have a one-to-one correspondence;

[0007] The scheduler is used to call the executable body in the executable body queue to execute the task corresponding to the called executable body on the thread of the scheduler.

[0008] The present application also provides a task scheduling method, including:

[0009] Determining the request time of the task assigned to each executor in the executor queue, wherein the executor and the assigned task have a one-to-one correspondence;

[0010] When the request time exceeds a first time threshold, sending a timeout message to a user of the task corresponding to the request time;

[0011] receiving an operation instruction sent by the user in response to the timeout information;

[0012] According to the operation instruction, a scheduler is used to call the corresponding execution body in the execution body queue to execute the task corresponding to the called execution body on the thread of the scheduler.

[0013] The embodiment of the present application also provides a task scheduling method, which is applied to a code environment other than a Linux operating system kernel, and the method includes:

[0014] Generate multiple tasks according to the received task request;

[0015] Allocating each task of the task request to an execution body scheduled by an underlying framework outside the kernel and forming an execution body queue, wherein the execution body and the assigned task have a one-to-one correspondence;

[0016] The underlying framework is used to call the executable body in the executable body queue, so as to execute the task corresponding to the called executable body on the thread of the underlying framework.

[0017] The present application also provides a task scheduling device, including:

[0018] A task group generation module, used for generating multiple tasks according to the received task request;

[0019] An allocation module, used for allocating each received task to an execution body and forming an execution body queue, wherein the execution body and the allocated task have a one-to-one correspondence;

[0020] A scheduler is used to call the executable body in the executable body queue to execute the task corresponding to the called executable body on the thread of the scheduler.

[0021] The present application also provides an electronic device, including:

[0022] Memory, used to store programs;

[0023] The processor is used to run the program stored in the memory, and the task scheduling method is executed when the program is running.

[0024] An embodiment of the present application further provides a computer-readable storage medium on which a computer program executable by a processor is stored, wherein the program, when executed by the processor, implements the task scheduling method as described above.

[0025] The task scheduling method and device, electronic device, and computer-readable storage medium of the embodiment of the present application can provide a method of allocating the split tasks to an executable body with higher flexibility, and use a scheduler running on each thread to schedule the executable body, so that the scheduler on the thread can realize the grouping and weight setting of the executable body corresponding to the task, and the scheduler bound to the thread can perform the scheduling and switching of the executable body with higher flexibility. Thus, while avoiding the consumption of thread scheduling system resources, flexibility is further ensured, and a balance between high concurrency and fairness is achieved.

[0026] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented in accordance with the contents of the specification. In order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are listed below. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present application. Also, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0028] Figure 1 A schematic diagram of an application scenario of the task scheduling method provided in an embodiment of the present application;

[0029] Figure 2 A flowchart of an embodiment of the task scheduling method provided by the present application;

[0030] Figure 3 A flowchart of another embodiment of the task scheduling method provided by the present application;

[0031] Figure 4 A schematic diagram of the structure of an embodiment of a task scheduling device provided by the present application;

[0032] Figure 5 A schematic diagram of the structure of an electronic device embodiment provided in this application. DETAILED DESCRIPTION

[0033] The exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although the exemplary embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. On the contrary, these embodiments are provided to enable a more thorough understanding of the present disclosure and to fully convey the scope of the present disclosure to those skilled in the art.

[0034] Embodiment 1

[0035] The solution provided in the embodiments of the present application can be applied to any computing system with task scheduling capabilities. Figure 1 A schematic diagram of an application scenario of the task scheduling method provided in an embodiment of the present application, Figure 1 The scenario shown is only one example of a scenario to which the technical solution of the present application can be applied.

[0036] With the development of Internet technology, more and more users use the Internet to retrieve and query information, and the development of cloud storage technology also makes it possible to store a large amount of data for users to query. When users perform such big data queries, they usually use a terminal or access a cloud server through the Internet to submit a query request (query). Figure 1 As shown in , such a query request will be split into multiple concurrently executable tasks by the search engine server that provides the search service. Therefore, in the prior art, query requests are usually split into as many concurrently executable tasks as possible, and the CPU computing resources are used as much as possible for parallel computing by executing multiple threads of the system to shorten the response time of big data query requests as much as possible. However, in actual applications, query requests often have different priorities. Therefore, in actual use, different response speeds are also required for requests of different priorities. This puts higher requirements on the concurrent allocation and execution of tasks, that is, interactive analysis products need to have strong concurrency and fairness. For example, Figure 1 As shown in , the query request 1 submitted by user 1 can be split into n tasks, namely, task 11 to task 1n, for concurrent execution. Afterwards, the n tasks split in this way can be assigned to multiple worker threads by the computing server that executes the query processing for parallel execution, so as to return the processing results in the shortest possible time.

[0037] In the prior art, multithreading or multiprocessing is used to process the tasks 11 to 1n into which the query request 1 is split, that is, each task is assigned a thread, and then the threads are scheduled to different CPUs using the scheduling mechanism of the Linux kernel. In this case, in order to meet the fairness requirement, Figure 1 In the case of trivial matters, the threads corresponding to the query request 1 submitted by user 1 and the query request 2 submitted by user 2 can be "grouped". The grouping capability provided by the Linux kernel is used to set weights for the "groups" to reflect the priority relationship between the query requests submitted by the users. In addition, the grouping relationship of these threads requires the kernel to be constantly adjusted according to the query requests currently received, which will bring considerable overhead. Alternatively, in the prior art, the grouping of these threads may not be adjusted for the newly received query requests, but a new thread may be created for each received query request to process, so that the overhead of thread creation and destruction will be greater.

[0038] In another prior art, the number of available threads is fixed, for example, the number of threads is set equal to the number of CPU cores, and then tasks 11 to 1n split according to query request 1 of user 1 are assigned to these threads for processing. However, pre-distribution may lead to an imbalance in the tasks queued on such a fixed number of threads, resulting in a "long tail".

[0039] In such task scheduling processing, with the development of Internet technology, the scenarios involving such query requests are becoming more and more complex. Therefore, the corresponding query requests are becoming more and more diverse and complex, while the computing resources of the processor, such as the number of CPU cores and the number of threads created, are limited. For example, at a certain moment, a large number of users may submit a large number of query requests that need to be processed by the system. Therefore, it is necessary to perform the above-mentioned task splitting on multiple different query requests at the same time and concurrently process the tasks of each request. Due to the diversity of query requests, for example, the processor may have different priorities and may also have different complexities. For example, the tasks split from query requests with higher priorities may be simple, that is, they can be completed by allocating fewer computing resources, but the tasks split from query requests with lower priorities may be relatively complex, that is, they need to allocate a large amount of computing resources to ensure the interactivity of the system. Therefore, in the existing query system, it is necessary to consider fairness when processing query requests, especially when allocating tasks for query requests, that is, considering the priorities of different query requests, that is, importance, and taking into account the efficiency of task execution, that is, it is necessary to provide strong concurrent performance and complete the tasks immediately to ensure interactivity. Therefore, in the prior art, there has been a method that can group threads corresponding to each task (work item) of a query request (query) according to the priority of the query request (query), and group different threads corresponding to different priorities. For example, a thread group corresponding to a task with a higher priority can contain more threads, that is, to ensure that more resources are inclined to tasks with higher priorities. That is, different weights are set for each thread group according to the priority of the task corresponding to the group. Thus, the CPU core can allocate CPU computing resources to the tasks corresponding to the threads in the thread group according to the weight value, and implement the scheduling and switching between the threads and the CPU core. However, such a scheme relies on the CPU core to be responsible for the allocation, scheduling and switching of threads. Therefore, when processing a large number of tasks, the large number of threads used will bring a large amount of grouping, scheduling and switching work, which will consume a large amount of CPU resources, thereby weakening concurrency. In addition, there is also a method of pre-setting a fixed number of working threads according to the number of CPU cores, that is, pre-binding the CPU core to the thread, so that the CPU does not need to create, call and switch threads, etc., and avoids the CPU resource consumption caused by scheduling and switching threads. However, as mentioned above, due to the large number of query requests, the number of tasks (workitems) is much higher than the number of threads determined and fixed in this way. Therefore, in this scheme, usually, a queuing task scheduling strategy is adopted that does not distinguish the priority of tasks but pre-assigns newly generated tasks to the thread with the least tasks for queuing.The scheduling method of pre-allocating tasks to queues saves the resource overhead caused by the CPU managing threads. However, since the assignment of tasks is predetermined, the running time of tasks cannot be considered during the assignment. As mentioned above, the diversity of query requests will make it difficult to estimate the running time of tasks in advance and may vary greatly. Therefore, such a pre-allocation method for queuing may cause uneven task distribution, such as a "long tail" effect, that is, due to the excessively long running time of a task in the queue, the tasks behind the queue are in a state of waiting for execution and are not executed, thus affecting the response time of other query requests. In addition, since the priority of query requests cannot be considered when pre-allocating tasks, the fairness between query requests cannot be guaranteed.

[0040] In this regard, the present application proposes to add an execution body to the existing task scheduling scheme as an intermediate receiver from task to thread, and accordingly set a scheduler on the thread, so as to use the scheduler to bind the thread, and the scheduler can perform scheduling for the execution body to indirectly schedule the task. For example, Figure 1 As shown in , in a scenario where two users initiate two query requests, user 1 can initiate query request 1, and user 2 can access the cloud server through its terminal or through the Internet to issue query request 2. The task scheduling system of the present application can divide the query request 1 into n tasks 11-1n after receiving it, and then directly assign these divided tasks one-to-one to the executables generated by the task scheduling system of the present application. For example, in an embodiment of the present application, the executables can be grouped according to priority as in the prior art, so that when the received query request 1 has a higher priority, tasks 11 to 1n can be assigned to the executable group 1 with a higher priority, and task 11 can be assigned to the executable 1 in group 1 in a one-to-one correspondence, and task 12 can be assigned to the executable 2, and so on, and finally task 1n can be assigned to the executable n. After being assigned to the executables 1 to n, the scheduler in the scheduler 1-p running on the thread 1-p can perform scheduling according to the load of the thread. For example, in Figure 1In the embodiment shown in , the scheduler 1 can schedule the execution body 1 to the thread 1 and execute it on the corresponding kernel 1, and the execution body 2 can be scheduled by the scheduler 2 to the thread 2 and execute it on the corresponding kernel 2, and so on, the execution bodies 1-n in the group 1 can be scheduled by different schedulers or can also be scheduled by the same scheduler to execute on the corresponding kernel on the thread run by the scheduler. Finally, after the execution bodies 1-n have been completed by each scheduler on the corresponding kernel, their execution results can be finally merged into a response 1 to output to the user 1. Of course, in the embodiment of the present application, since each scheduler in the scheduler 1-p schedules the execution of the query request task 11-1n according to the load on its thread, before generating the response 1, the results of the executed execution bodies can be temporarily stored, and after waiting for the results of other execution bodies to be completed, they can be merged together to generate a response 1 to send to the user 1.

[0041] In an embodiment of the present application, these execution bodies are similar to threads, which are generated in advance by the task scheduling system of the present application or when the query request 1 is received, and the execution body can run on one CPU and can also migrate between different CPUs according to the instructions of the task scheduling system. In other words, in the present application, the execution body can be used as an intermediate between multiple tasks split out of the query request as a task request and the thread that executes the task, which can be scheduled not by the system kernel, but by the task scheduling system of the embodiment of the present application, or can be regarded as an ultra-lightweight thread. In the present application, the execution body is conceptually similar to a thread, each execution body can correspond to a context, can only run on one cpu at the same time, and the execution body can also migrate between different cpu. However, unlike the execution unit in the prior art, the execution body in the present application is not scheduled by the kernel of the operating system, but is scheduled by, for example, the underlying framework of the engine. Therefore, as mentioned above, the execution body in the present application can be equivalent to an ultra-lightweight thread, and the overhead of switching, creating, and destroying it is very low, and there can be any number of input / output (IO) concurrency within an execution body, that is, the IO asynchronous call encapsulated by the underlying framework of the engine ensures that the execution body of the present application will not be blocked when waiting for IO, let alone the working thread.

[0042] Therefore, after the tasks are assigned to each execution body, an execution body queue can be formed, that is, the execution bodies corresponding to the tasks that are ready to be executed are formed into an execution body queue, so that the scheduler running on each thread can be scheduled. For example, unlike the prior art that uses the kernel of the operating system for scheduling, that is, the kernel of the operating system is used as a scheduler, in the embodiment of the present application, a scheduler can be run on each working thread, which can be an asynchronous scheduler, that is, the scheduler in the embodiment of the present application will not immediately perform scheduling processing on the newly assigned execution body, but will first add it to the execution body queue, and then schedule the execution body in the execution body queue according to the execution situation, and when the execution body completes the current task and enters the blocking state, its corresponding scheduler will not enter the blocking state, but continue to schedule other execution bodies, that is, although there is a corresponding relationship between the scheduler and its corresponding execution body, the scheduling is performed in an asynchronous manner, that is, after the execution body is assigned to the scheduler, the scheduler does not directly perform scheduling immediately, but waits for a suitable time to perform scheduling, and after the execution body completes the task, the scheduler will not enter the blocking state synchronously with it, but schedules other execution bodies. For example, the tasks corresponding to the execution bodies in the execution body queue are all tasks that are ready to be executed. Therefore, the execution bodies in the execution body queue can be scheduled by the scheduler running on the working thread, thereby realizing the allocation of each task to the working thread. That is, in the present application, by allocating tasks to the execution body in a one-to-one correspondence, and running each scheduler on each thread, the allocation between tasks and threads is realized as a more flexible scheduling between the scheduler and the execution body. In particular, since the execution body is created and managed by the task scheduling system of the embodiment of the present application, there is no need to consume the computing resources of the system kernel, especially the CPU, and the scheduler is bound to the thread, and then the balance of tasks on the thread is maintained at any time through the scheduling of the execution body by the scheduler, avoiding the "long tail" phenomenon caused by the unreasonable allocation of tasks in the prior art.

[0043] After each thread has processed the tasks corresponding to the execution body scheduled by the scheduler, such as Figure 1 As shown in , a corresponding response can be generated according to the execution result and sent to the user.

[0044] Therefore, the task scheduling scheme of the embodiment of the present application can provide the allocation of split tasks to the execution bodies with higher flexibility, and use the scheduler running on each thread to schedule the execution bodies, so that the grouping and weight setting of the execution bodies corresponding to the tasks can be realized through the scheduler on the thread, and the scheduling and switching of the execution bodies with higher flexibility can be performed by the scheduler bound to the thread. In this way, flexibility can be further ensured while avoiding the consumption of computing resources of the system kernel that schedules the process, and a balance between high concurrency and fairness can be achieved.

[0045] In addition, according to an embodiment of the present application, a user can use a cloud server to which a task scheduling scheme of an embodiment of the present application is applied. For example, when providing a cloud service on such a cloud server for a user, the received big data interaction request can be split using the task scheduling of the embodiment of the present application in the user's cloud server according to the received big data interaction request, and the split tasks can be assigned to the execution body in the embodiment of the present application, thereby providing a more balanced resource scheduling for the big data calculation in the user's cloud server compared to the prior art directly assigned to threads or using a scheduler to perform queuing. Therefore, when a user uses a cloud server to which a task scheduling scheme of an embodiment of the present application is applied, since the task scheduling scheme of the embodiment of the present application can more evenly balance concurrency and fairness, it can achieve a higher computing resource utilization for the user, so that the user can use a lower computing resource configuration than the prior art for cloud computing processing, thereby not only improving the computing efficiency of the cloud service provided to the user, but also saving the user's cloud service overhead.

[0046] The above embodiments are illustrations of the technical principles and exemplary application frameworks of the embodiments of the present application. The specific technical solutions of the embodiments of the present application are further described in detail below through multiple embodiments.

[0047] Embodiment 2

[0048] Figure 2 This is a flowchart of an embodiment of the task scheduling method provided by the present application. The execution subject of the method can be various terminals or server devices with thread management capabilities, or it can be a device or chip integrated on these devices. Figure 2 As shown, the task allocation calculation method includes the following steps:

[0049] S201, generating multiple tasks according to the received task request.

[0050] In the embodiment of the present application, the user can submit his task request by using a terminal or accessing the cloud server through the Internet. For example, the user can usually submit a query request for big data to retrieve the content he wants from the large amount of data stored on the cloud server. Therefore, after receiving the task request in the embodiment of the present application, Figure 1 As shown in , multiple tasks are generated according to the task request. In other words, in the embodiment of the present application, the task request can be split into multiple tasks that can be executed concurrently, and each of them executes a part of the content of the task request.

[0051] S202, allocating each task of the task request to an execution body and forming an execution body queue.

[0052] In the embodiment of the present application, after multiple tasks for concurrent execution are obtained in step S201, the tasks can be assigned to the execution body created by the task scheduling system of the present application so as to be assigned to the thread for execution. For example, in the embodiment of the present application, the tasks can be assigned to the execution body in a one-to-one manner, that is, Figure 1 As shown in , each execution body corresponds one-to-one to the task obtained in step S201. In an embodiment of the present application, the execution bodies can also be grouped, so that each group can correspond to a task request, that is, multiple execution bodies in an execution body group respectively correspond to multiple tasks split out of a task request, so that task scheduling can be performed with the group as a unit. In addition, in step S202, after the task is assigned to the execution body, an execution body queue can be further formed according to the allocation status of the task to the execution body, for example, whether the allocation has been completed, that is, the task is ready and can be scheduled to the thread for execution and processing, so that the execution bodies in the execution body queue are all execution bodies that can be scheduled to be assigned to the working thread for execution.

[0053] S203: Use the scheduler to call the executable in the executable queue to execute the task corresponding to the called executable on the thread of the scheduler.

[0054] In the embodiment of the present application, a scheduler may be run on each working thread, which may be an asynchronous scheduler. For example, the tasks corresponding to the executables in the executable queue formed in step S202 are all tasks that are ready to be executed, so the executables in the executable queue may be scheduled by the scheduler running on the working thread, thereby realizing the allocation of each task to the working thread.

[0055] For example, in the present application, in step S201, tasks are assigned to execution bodies in a one-to-one relationship, and in step S203, the execution bodies are scheduled by each scheduler running on each thread, so that each task is scheduled accordingly, so that the assignment between tasks and threads is implemented as a more flexible scheduling between schedulers and execution bodies. In particular, since the execution body is created and managed by the task scheduling system of the embodiment of the present application, there is no need to consume the computing resources of the system kernel, especially the CPU, and the scheduler is bound to the thread, and then the balance of tasks on the thread can be maintained at any time by scheduling the execution body by the scheduler, avoiding the "long tail" phenomenon caused by unreasonable task allocation in the prior art.

[0056] Therefore, the task scheduling scheme of the embodiment of the present application can provide the allocation of split tasks to the execution bodies with higher flexibility, and use the scheduler running on each thread to schedule the execution bodies, so that the scheduler on the thread can realize the grouping and weight setting of the execution bodies corresponding to the tasks, and the scheduler bound to the thread can perform the scheduling and switching of the execution bodies with higher flexibility. In this way, while avoiding the consumption of thread scheduling system resources, flexibility is further ensured, and a balance between high concurrency and fairness is achieved.

[0057] Embodiment 3

[0058] Figure 3 This is a flowchart of another embodiment of the task scheduling method provided by the present application. The execution subject of the method can be various terminals or server devices with thread management capabilities, or devices or chips integrated on these devices. Figure 3 As shown, the task allocation calculation method includes the following steps:

[0059] S301, generating multiple tasks according to the received task request.

[0060] In the embodiment of the present application, the user can submit his task request by using a terminal or accessing the cloud server through the Internet. For example, the user can usually submit a query request for big data to retrieve the content he wants from the large amount of data stored on the cloud server. Therefore, after receiving the task request in the embodiment of the present application, Figure 1 As shown in , multiple tasks are generated according to the task request. In other words, in the embodiment of the present application, the task request can be split into multiple tasks that can be executed concurrently, and each of them executes a part of the content of the task request.

[0061] S302, allocating each task of the task request to an execution body and forming an execution body queue.

[0062] In the embodiment of the present application, after multiple tasks for concurrent execution are obtained in step S301, the tasks can be assigned to the execution body created by the task scheduling system of the present application so as to be assigned to the thread for execution. For example, in the embodiment of the present application, the tasks can be assigned to the execution body in a one-to-one manner, that is, Figure 1 As shown in , each execution body corresponds to the task obtained in step S301 one by one. In an embodiment of the present application, each execution body in the execution body queue can be assigned a predetermined time quota, that is, the execution body in the execution body queue can be set or specified in advance for the time length allowed to be scheduled for execution, so that when it is scheduled by the thread to execute the corresponding task, it can be determined according to the time quota whether the task is executed beyond the predetermined time threshold. In addition, in an embodiment of the present application, the execution body can also be grouped, so that each group can correspond to a task request, that is, a plurality of execution bodies in an execution body group respectively correspond to a plurality of tasks split out of a task request, so that task scheduling can be performed with the group as a unit. In addition, in step S302, after the task is assigned to the execution body, the execution body queue can be further formed according to the distribution state of the task to the execution body, for example, whether the distribution has been completed, that is, the task is ready to be scheduled to the thread for execution processing, so that the execution bodies in the execution body queue are all execution bodies that can be scheduled to be assigned to the working thread for execution.

[0063] In the embodiment of the present application, a scheduler may be run on each working thread, which may be an asynchronous scheduler. For example, the tasks corresponding to the executables in the executable queue formed in step S302 are all tasks that are ready to be executed. Therefore, the executables in the executable queue may be scheduled by the scheduler running on the working thread, thereby realizing the allocation of each task to the working thread.

[0064] S3031, using the scheduler running on the thread to call the executor in the executor queue, so as to execute the corresponding task on the thread of the scheduler within the time quota of the called executor.

[0065] For example, in the embodiment of the present application, when the execution body is assigned a time quota, the scheduler in step S3031 can schedule the execution body in the execution body queue according to various scheduling strategies to execute the task corresponding to the execution body within the time quota corresponding to the execution body. That is, the scheduler of each thread can stop the execution of the task currently being executed when the time quota is exceeded, and switch to another task for execution, thereby preventing the "long tail" caused by the long execution time of the task in the thread in the prior art.

[0066] S3032, determining whether the execution of the task is in the first state of data reading and writing.

[0067] S3033: When it is determined that the execution of the task is in the first state, the execution body is put into a blocking state, and the execution body is removed from the execution body queue.

[0068] In an embodiment of the present application, during the execution of a task, the scheduler may further determine whether the execution of the task is in a first state of data reading and writing, for example, a state of data reading and writing (IO). For example, the scheduler may determine whether it is in a first state of data reading and writing by a read and write instruction of a memory or a controller of the memory used to perform data reading and writing or a change in the current working state of the disk. When a task is performing data reading and writing, the task is usually suspended to wait for the completion of the read and write operation. Therefore, in an embodiment of the present application, when it is determined that the task executed on the thread is in a state of data reading and writing, the execution body corresponding to the task may be made to enter a blocking state, that is, the execution body remains associated with the current task, and the execution body may be removed from the execution body queue, so that the execution body will not be scheduled by the scheduler on other threads.

[0069] S3034, determine whether data reading and writing are completed.

[0070] S3035, when it is determined that the data reading and writing are completed, the execution body is made to exit the blocking state.

[0071] In an embodiment of the present application, when the data read and write operation of the task corresponding to the blocked execution body has been completed, the execution body can be exited from the blocked state in response to the completion of the operation. For example, when the scheduler on the thread has executed all the execution bodies in the current queue, that is, when there are no remaining ready execution bodies in the current queue that have not been scheduled by the scheduler, the scheduler can determine whether the IO operation of the task corresponding to the execution body in the blocked state has been completed. For example, the scheduler can use epoll_wait to check the asynchronous IO event of the task, and then perform corresponding operations on the execution in the blocked state according to the return result of the epoll_wait. For example, when the return result indicates that the IO event has ended, that is, the data read and write operation of the corresponding task has been completed, the scheduler can wake up the execution body in the blocked state, so that the execution body exits the blocked state.

[0072] Therefore, the execution body that exits the blocking state according to the completion of the data read and write operation in step S3035 can be re-added to the execution body queue and scheduled for execution by the scheduler.

[0073] Therefore, the task scheduling scheme of the embodiment of the present application can provide the allocation of split tasks to the execution bodies with higher flexibility, and use the scheduler running on each thread to schedule the execution bodies, so that the grouping and weight setting of the execution bodies corresponding to the tasks can be realized through the scheduler on the thread, and the scheduling and switching of the execution bodies with higher flexibility can be performed by the scheduler bound to the thread. In this way, flexibility can be further ensured while avoiding the consumption of computing resources of the system kernel that schedules the process, and a balance between high concurrency and fairness can be achieved.

[0074] Embodiment 4

[0075] Figure 4 The schematic diagram of the structure of the task scheduling device embodiment provided in the present application can be used to execute the following steps: Figure 2 and Figure 3 The method steps shown. Figure 4 As shown, the task scheduling device may include: a task generating module 41 , an allocating module 42 and a scheduler 43 .

[0076] The task generation module 41 may be configured to generate a plurality of tasks according to a received task request.

[0077] In the embodiment of the present application, the user can submit his task request by using a terminal or accessing the cloud server through the Internet. For example, the user can usually submit a query request for big data to retrieve the content he wants from the large amount of data stored on the cloud server. Therefore, after receiving the task request in the embodiment of the present application, Figure 1 As shown in , multiple tasks are generated according to the task request. In other words, in the embodiment of the present application, the task generation module 41 can be used to split the task request into multiple tasks that can be executed concurrently, which respectively execute a part of the content of the task request.

[0078] The allocation module 42 may be used to allocate each task of the task request to an execution body and form an execution body queue.

[0079] In the embodiment of the present application, after the task generation module 41 generates multiple tasks for concurrent execution, the allocation module 42 can allocate the tasks to the execution body created by the task scheduling system of the present application so as to allocate them to the threads for execution. For example, in the embodiment of the present application, the allocation module 42 can allocate the tasks generated by the task generation module 41 to the execution body in a one-to-one manner. For example, Figure 1As shown in , the tasks assigned by the allocation module 42 can correspond to each execution body one by one. In addition, after the allocation module 42 assigns the task to the execution body, it can further form an execution body queue according to the assignment status of the task to the execution body, for example, whether the assignment has been completed, that is, the task is ready to be scheduled to the thread for execution, so that the execution bodies in the execution body queue are all execution bodies that can be scheduled to be assigned to the working thread for execution. In an embodiment of the present application, each execution body in the execution body queue can be assigned a predetermined time quota, that is, the execution body in the execution body queue can be set or specified in advance for the execution body to be scheduled for execution. When it is scheduled by the thread to perform the corresponding task, it can be determined according to the time quota whether the task is executed beyond a predetermined time threshold. In addition, in an embodiment of the present application, the execution body can also be grouped, so that each group can correspond to a task request, that is, multiple execution bodies in an execution body group correspond to multiple tasks split out of a task request, so that task scheduling can be performed with the group as a unit.

[0080] The scheduler 43 may run on a thread and is used to call an executable in an executable queue to execute a task corresponding to the called executable on the thread.

[0081] In the embodiment of the present application, the scheduler 43 can run on a working thread. In other words, one scheduler 43 can correspond to a working thread, for example, it can be bound to a working thread. In the embodiment of the present application, the scheduler 43 can be an asynchronous scheduler. For example, the tasks corresponding to the executables in the executable queue formed by the allocation module 42 are all tasks that are ready to be executed. Therefore, the executables in the executable queue can be scheduled by the scheduler 43 running on the working thread, thereby realizing the allocation of each task to the working thread.

[0082] For example, in the present application, the allocation module 42 can allocate tasks to the execution body in a one-to-one relationship, and schedule the execution body through each scheduler 43 running on each thread, so as to schedule each task accordingly, thereby implementing the allocation between tasks and threads as a more flexible scheduling between the scheduler and the execution body. In particular, since the execution body is created and managed by the task scheduling system of the embodiment of the present application, there is no need to consume the computing resources of the system kernel, especially the CPU, and the scheduler is bound to the thread, and then the balance of tasks on the thread can be maintained at any time by scheduling the execution body by the scheduler, avoiding the "long tail" phenomenon caused by unreasonable task allocation in the prior art.

[0083] In addition, in the embodiment of the present application, when the execution body is assigned a time quota, the scheduler 43 can further schedule the execution body in the execution body queue according to various scheduling strategies to execute the task corresponding to the execution body within the time quota corresponding to the execution body. That is, the scheduler of each thread can stop the execution of the task currently being executed when the time quota is exceeded, and switch to another task for execution, thereby preventing the "long tail" caused by the long execution time of the task in the thread in the prior art.

[0084] In addition, in an embodiment of the present application, the scheduler 43 can be further used to determine whether the execution of the task is in the first state of data reading and writing, and when it is determined that the execution of the task is in the first state, the execution body is put into a blocking state and the execution body is moved out of the execution body queue.

[0085] In the embodiment of the present application, during the execution of the task, the scheduler 43 can further determine whether the execution of the task is in a state of data reading and writing (IO). When the task is reading and writing data, the task is usually suspended to wait for the completion of the read and write operation. Therefore, in the embodiment of the present application, when it is determined that the task executed on the thread is in a state of data reading and writing, the execution body corresponding to the task can be made to enter a blocking state, that is, the execution body remains associated with the current task, and the execution body can be removed from the execution body queue, so that the execution body will not be scheduled by the scheduler on other threads.

[0086] In addition, in the embodiment of the present application, the scheduler 43 can be further used to determine whether the data reading and writing is completed, and when it is determined that the data reading and writing is completed, the execution body exits the blocking state.

[0087] In an embodiment of the present application, when the data read and write operation of the task corresponding to the blocked execution body has been completed, the execution body can be exited from the blocked state in response to the completion of the operation. For example, when the scheduler 43 on the thread has executed all the execution bodies in the current queue, that is, when there are no remaining ready execution bodies in the current queue that have not been scheduled by the scheduler 43, the scheduler 43 can determine whether the IO operation of the task corresponding to the execution body in the blocked state has been completed. For example, the scheduler 43 can use epoll_wait to check the asynchronous IO event of the task, and then perform corresponding operations on the execution in the blocked state according to the return result of the epoll_wait. For example, when the return result indicates that the IO event has ended, that is, the data read and write operation of the corresponding task has been completed, the scheduler can wake up the execution body in the blocked state, so that the execution body exits the blocked state.

[0088] Therefore, the execution body that exits the blocking state according to the completion of the data read and write operation can be re-added to the execution body queue and scheduled for execution by the scheduler 43.

[0089] In addition, according to an embodiment of the present application, the task scheduling device may further include a load balancing module 44, which may be used to control the multiple schedulers to respectively call the executables in the executable queue according to the load conditions of the multiple schedulers. That is, when the tasks corresponding to the executables scheduled by the schedulers to their respective threads have been completed or the queue of the thread corresponding to the scheduler is long due to the complexity of the currently executed task causing the execution event to be long, the load balancing module 44 may be used to control the schedulers to respectively call the executables in the executable queue according to such load conditions to flexibly allocate tasks.

[0090] Therefore, the task scheduling scheme of the embodiment of the present application can provide the allocation of split tasks to the execution bodies with higher flexibility, and use the scheduler running on each thread to schedule the execution bodies, so that the grouping and weight setting of the execution bodies corresponding to the tasks can be realized through the scheduler on the thread, and the scheduling and switching of the execution bodies with higher flexibility can be performed by the scheduler bound to the thread. In this way, flexibility can be further ensured while avoiding the consumption of computing resources of the system kernel that schedules the process, and a balance between high concurrency and fairness can be achieved.

[0091] Embodiment 5

[0092] The internal functions and structure of the text processing device are described above. The device can be implemented as an electronic device. Figure 5 This is a schematic diagram of the structure of an electronic device embodiment provided by this application. Figure 5 As shown, the electronic device includes a memory 51 and a processor 52 .

[0093] The memory 51 is used to store programs. In addition to the above programs, the memory 51 can also be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method operating on the electronic device, contact data, phone book data, messages, pictures, videos, etc.

[0094] The memory 51 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk.

[0095] The processor 52 is not limited to a central processing unit (CPU), but may also be a processing chip such as a graphics processing unit (GPU), a field programmable gate array (FPGA), an embedded neural network processor (NPU) or an artificial intelligence (AI) chip. The processor 52 is coupled to the memory 51 and executes the program stored in the memory 51. When the program is running, the task scheduling method of the above-mentioned embodiments 2 and 3 is executed.

[0096] Further, if Figure 5 As shown, the electronic device may also include: a communication component 53, a power component 54, an audio component 55, a display 56 and other components. Figure 5 Only some components are shown schematically, which does not mean that the electronic device only includes Figure 5 Components shown.

[0097] The communication component 53 is configured to facilitate wired or wireless communication between the electronic device and other devices. The electronic device can access a wireless network based on a communication standard, such as WiFi, 3G, 4G or 5G, or a combination thereof. In an exemplary embodiment, the communication component 53 receives a broadcast signal or broadcast-related information from an external broadcast management system via a broadcast channel. In an exemplary embodiment, the communication component 53 also includes a near field communication (NFC) module to facilitate short-range communication. For example, the NFC module can be implemented based on radio frequency identification (RFID) technology, infrared data association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology and other technologies.

[0098] The power supply component 54 provides power to various components of the electronic device. The power supply component 54 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to the electronic device.

[0099] The audio component 55 is configured to output and / or input audio signals. For example, the audio component 55 includes a microphone (MIC), and when the electronic device is in an operating mode, such as a call mode, a recording mode, and a voice recognition mode, the microphone is configured to receive an external audio signal. The received audio signal can be further stored in the memory 51 or sent via the communication component 53. In some embodiments, the audio component 55 also includes a speaker for outputting audio signals.

[0100] The display 56 includes a screen, which may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touch screen to receive input signals from a user. The touch panel includes one or more touch sensors to sense touch, slide, and gestures on the touch panel. The touch sensor may not only sense the boundary of a touch or slide action, but also detect the duration and pressure associated with the touch or slide operation.

[0101] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0102] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present invention.

Claims

1. A task scheduling method, comprising: Generate multiple tasks that can be executed concurrently according to the received task requests; Allocating each task of the task request to an execution body and forming an execution body queue according to the assignment status of the task to the execution body, wherein the execution body and the assigned task have a one-to-one correspondence; the execution body is created, managed and scheduled by the task scheduling system; The asynchronous scheduler running on the thread is used to call the executor in the executor queue to group the executors corresponding to the tasks and set the weights, and the tasks are scheduled with the group as a unit, and the tasks corresponding to the called executors are executed on the thread of the scheduler.

2. The task scheduling method according to claim 1, wherein: Each executor in the executor queue is assigned a predetermined time quota, and, The asynchronous scheduler running on the thread is used to call the executor in the executor queue to group the executors corresponding to the tasks and set the weights, and the tasks are scheduled with the group as a unit, and the tasks corresponding to the called executors are executed on the thread of the scheduler, including: The scheduler running on the thread is used to call the executor in the executor queue to execute the corresponding task on the thread of the scheduler within the time quota of the called executor.

3. The task scheduling method according to claim 1, wherein: The using an asynchronous scheduler running on the thread to call the executable in the executable queue includes: Determining whether the execution of the task is in a first state of data reading and writing; When it is determined that the execution of the task is in the first state, the execution body is made to enter a blocking state, and the execution body is removed from the execution body queue.

4. The task scheduling method according to claim 3, wherein: The method of using an asynchronous scheduler running on a thread to call an executable in the executable queue further includes: Determine whether the data reading and writing is completed; When it is determined that the data reading and writing is completed, the execution body is made to exit the blocking state.

5. The task scheduling method according to claim 1, wherein: The using an asynchronous scheduler running on the thread to call the executable in the executable queue includes: Multiple schedulers are used to respectively call the executable bodies in the executable body queue according to the load conditions of the multiple schedulers.

6. The task scheduling method according to claim 1, wherein: The task runs in the operating system, and The execution body is scheduled by a scheduler on the thread and is not subject to the scheduling control of the kernel of the operating system; The execution body migrates between different processors according to the scheduling of the scheduler.

7. The task scheduling method according to claim 3, wherein: When the execution body enters the blocking state, the scheduler corresponding to the execution body calls other execution bodies in the execution body queue to execute corresponding tasks on the thread of the scheduler.

8. The task scheduling method according to claim 4, wherein: When it is determined that the data reading and writing is completed, causing the execution body to exit the blocking state further includes: The execution body that will exit the blocking state is called again by the scheduler.

9. The task scheduling method according to claim 4, wherein: When it is determined that the data reading and writing is completed, causing the execution body to exit the blocking state further includes: The scheduler sends a wake-up instruction to the execution body in the blocking state, so that the execution body exits the blocking state.

10. A task scheduling method, comprising: Determining the request time of concurrently executable tasks assigned to each executor in the executor queue, wherein the executor and the assigned task have a one-to-one correspondence; the executor is created, managed and scheduled by the task scheduling system; When the request time exceeds a first time threshold, sending a timeout message to a user of the task corresponding to the request time; receiving an operation instruction sent by the user in response to the timeout information; According to the operation instruction, the asynchronous scheduler running on the thread is used to call the corresponding executor in the executor queue to realize the grouping and weight setting of the executors corresponding to the tasks, and the task scheduling is performed with the group as a unit, and the task corresponding to the called executor is executed on the thread of the scheduler; the executor queue is formed according to the allocation status of the tasks to the executors.

11. A task scheduling method, the task scheduling method being applied in a code environment other than a Linux operating system kernel, the method comprising: Generate multiple tasks that can be executed concurrently according to the received task requests; Allocating each task of the task request to an execution body scheduled by an underlying framework outside the kernel and forming an execution body queue according to the assignment status of the task to the execution body, wherein the execution body and the assigned task have a one-to-one correspondence; the execution body is created, managed and scheduled by a task scheduling system; The underlying framework running on the thread is used to asynchronously call the executor in the executor queue to group the executors corresponding to the tasks and set their weights, and the task scheduling is performed using the group as a unit, and the task corresponding to the called executor is executed on the thread of the underlying framework.

12. A task scheduling device, comprising: A task generation module, used to generate multiple tasks that can be executed concurrently according to the received task request; An allocation module, used to allocate each received task to an execution body and form an execution body queue according to the allocation status of the task to the execution body, wherein the execution body and the allocated task have a one-to-one correspondence; the execution body is created, managed and scheduled by the task scheduling system; The scheduler running on the thread is used to asynchronously call the executor in the executor queue to group the executors corresponding to the tasks and set their weights, schedule tasks with the group as a unit, and execute the tasks corresponding to the called executors on the thread of the scheduler.

13. The task scheduling device according to claim 12, wherein: Each executor in the executor queue is assigned a predetermined time quota, and, The scheduler is used to call the executor in the executor queue to execute the corresponding task on the thread of the scheduler within the time quota of the called executor.

14. An electronic device, characterized in that: include: Memory, used to store programs; A processor is used to run the program stored in the memory, and the program executes the task scheduling method as described in any one of claims 1 to 11 when it is run.

15. A computer-readable storage medium having stored thereon a computer program executable by a processor, wherein: When the program is executed by a processor, the task scheduling method as described in any one of claims 1 to 11 is implemented.

Images