A computing resource scheduling method, medium and computing device

Abstract

Embodiments disclosed in the specification provide a computing resource scheduling method, medium and computing device. A process can implement a computing task by creating a work coroutine instead of creating a work thread. In order to facilitate flexible limitation of computing resources consumed by the process, the work coroutines can be grouped, and a corresponding consumable computing resource upper limit is set for each work coroutine group. Meanwhile, the process also creates a plurality of scheduling threads, which are responsible for managing the scheduling of computing resources of a processor, and are also responsible for managing that the total amount of computing resources consumed by a work coroutine group does not exceed the corresponding consumable computing resource upper limit of the work coroutine group.

Description

Technical Field

[0001] This specification relates to the field of information technology in several embodiments, and in particular to a computing resource scheduling method, medium and computing device. Background Technology

[0002] In some business scenarios, users can run their processes on computing devices. These processes can create multiple worker threads to execute computational tasks, which consume the computing resources of the device. Given limited computing resources, it's crucial to allocate them efficiently to prevent situations where some worker threads consume resources without restriction while others struggle to access them.

[0003] Therefore, a more effective method for scheduling computing resources is needed. Summary of the Invention

[0004] Several embodiments of this specification provide a processor computing resource scheduling method and medium, so as to utilize the processor's computing resources as efficiently as possible while flexibly limiting the computing resources consumed by processes.

[0005] The technical solutions provided in several embodiments of this specification are as follows:

[0006] According to a first aspect of several embodiments of this specification, a computing resource scheduling method is proposed, applied to a computing device, wherein processes of the computing device create several worker coroutine groups and several scheduling threads, the method comprising:

[0007] Any working coroutine in the coroutine group enters the ready queue;

[0008] Any scheduling thread reads a worker coroutine from the ready queue and determines whether the read worker coroutine meets the scheduling conditions; wherein, the scheduling conditions include: the total amount of computing resources consumed by the worker coroutine group to which the worker coroutine belongs does not exceed the upper limit of the consuming computing resources corresponding to the worker coroutine group;

[0009] If the determination result is yes, the scheduling thread provides resource scheduling for the working coroutine; if the determination result is no, the scheduling thread refuses to provide resource scheduling for the working coroutine.

[0010] If allowed to occupy the scheduling thread, the worker coroutine continues to consume the computing resources scheduled by the scheduling thread; and the occupation of the scheduling thread is released after the execution state is interrupted.

[0011] According to a second aspect of several embodiments of this specification, a computing device is provided, including a memory and a processor; the memory is used to store computer instructions executable on the processor, and the processor is used to implement the method of the first aspect when executing the computer instructions.

[0012] According to a third aspect of several embodiments of this specification, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method of the first aspect.

[0013] In the above technical solution, processes can perform computational tasks by creating worker coroutines (rather than worker threads). To facilitate flexible limitation of the computing resources consumed by processes, worker coroutines can be grouped, and a corresponding upper limit on the computing resources that each worker coroutine group can consume can be set. Simultaneously, the process also creates several scheduling threads, which are responsible for managing the scheduling of processor computing resources and ensuring that the total computing resources consumed by a worker coroutine group do not exceed the upper limit of the computing resources that worker coroutine group can consume.

[0014] In its implementation, each worker coroutine enters the ready queue after its execution state is ready. The scheduling thread reads worker coroutines from the ready queue. If the total computing resources consumed by the worker coroutine group to which the worker coroutine belongs exceed the upper limit of the computing resources that the worker coroutine group can consume, the scheduling thread refuses to offer itself to the worker coroutine for use. If the total computing resources consumed by the worker coroutine group to which the worker coroutine belongs do not exceed the upper limit of the computing resources that the worker coroutine group can consume, the scheduling thread offers itself to the worker coroutine for use so that computing resources can be scheduled for the worker coroutine. If any worker coroutine occupies a scheduling thread, it continues to consume the computing resources scheduled by that scheduling thread, and releases its occupation of the scheduling thread after the execution state of the worker coroutine is interrupted.

[0015] When computing resources are limited, threads in the ready state will compete for these resources. Even if a thread's execution state is interrupted after it has acquired a resource, it will continue to consume that resource without relinquishing its demand. This prevents other threads from fully utilizing the resources, resulting in wasted computing power. Coroutines, unlike threads, can "friendly" share computing resources. When a coroutine's execution state is interrupted, it automatically relinquishes its demand for computing resources (this can be described as a coroutine actively suspending itself after an interruption), without affecting other coroutines' use of the resources, thus improving resource utilization.

[0016] Furthermore, to prevent coroutines from demanding unlimited computing resources, coroutines need to be grouped, and each coroutine group needs to be configured with a corresponding upper limit on the computing resources it can consume. The process needs to create several scheduling threads to manage the scheduling of computing resources. These threads can schedule computing resources for a coroutine only if they determine that the total amount of computing resources consumed by the coroutine group to which it belongs has not exceeded the limit. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a computing resource scheduling method provided in this specification.

[0018] Figure 2 An example of a processor's computing resource scheduling process is provided.

[0019] Figure 3 This is a schematic diagram of the structure of a computing device provided in this disclosure.

[0020] In the accompanying drawings, identical or corresponding reference numerals denote identical or corresponding parts. Any number of elements in the drawings is for illustrative purposes only and not for limitation, and any naming is for distinction only and has no limiting meaning. Detailed Implementation

[0021] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0022] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0023] In some business scenarios, users can run their processes on computing devices. These processes can create multiple worker threads to execute computational tasks, which consume the computing resources of the device's processor. Given limited computing resources, it's crucial to schedule these resources efficiently to prevent some worker threads from consuming resources without restriction while others struggle to access them.

[0024] One feasible computing resource scheduling scheme is to use cgroup technology to group multiple worker threads created by a process and configure a corresponding upper limit of consuming computing resources for each worker thread group. The cgroup controller can schedule computing resources for each worker thread while taking into account the upper limit of consuming computing resources for each worker thread group.

[0025] Because computing resources are limited, threads in the execution state that are ready will compete for computing resources. After a thread has acquired computing resources, it will continue to consume computing resources even if its execution state is interrupted, and will not withdraw its demand for computing resources. This causes other threads to be unable to make full use of computing resources, resulting in a waste of computing resources. Therefore, the cgroup controller usually actively performs thread switching operations, that is, switching the worker thread that is continuously consuming computing resources from one worker thread whose execution state is interrupted to another worker thread that is ready to execute.

[0026] However, the above-mentioned feasible solutions have certain drawbacks. First, the cgroup controller usually runs in the processor's kernel mode, while the worker threads created by the process usually run in the processor's user mode. When the controller performs thread switching operations, it involves switching between kernel mode and user mode, which will cause additional consumption of computing resources.

[0027] Secondly, in cloud computing scenarios, users run their processes in virtual machines, which are then deployed within virtual machine containers on cloud servers (common examples include Kubernetes containers). However, these containers typically do not support modifications to cgroups. This means that the worker thread groups configured during process initialization, and the maximum computing resources each worker thread group can consume, are difficult to change. Consequently, it is inconvenient for users if they cannot easily modify these worker thread groups and their maximum computing resources based on changes in their actual business needs.

[0028] Therefore, this disclosure provides another technical solution. A process can perform computational tasks by creating worker coroutines (instead of worker threads). To facilitate flexible limitation of the computational resources consumed by a process, worker coroutines can be grouped, and a corresponding upper limit on the computational resources that each worker coroutine group can consume can be set. Simultaneously, the process also creates several scheduling threads, which are responsible for managing the scheduling of processor computational resources and ensuring that the total amount of computational resources consumed by a worker coroutine group does not exceed the upper limit of the computational resources that worker coroutine group can consume.

[0029] In its implementation, each worker coroutine enters the ready queue after its execution state is ready. The scheduling thread reads worker coroutines from the ready queue. If the total computing resources consumed by the worker coroutine group to which the worker coroutine belongs exceed the upper limit of the computing resources that the worker coroutine group can consume, the scheduling thread refuses to offer itself to the worker coroutine for use. If the total computing resources consumed by the worker coroutine group to which the worker coroutine belongs do not exceed the upper limit of the computing resources that the worker coroutine group can consume, the scheduling thread offers itself to the worker coroutine for use so that computing resources can be scheduled for the worker coroutine. If any worker coroutine occupies a scheduling thread, it continues to consume the computing resources scheduled by that scheduling thread, and the occupation of the scheduling thread is released after the execution state of the worker coroutine is interrupted.

[0030] When computing resources are limited, threads in the ready state will compete for these resources. Even if a thread's execution state is interrupted after it has acquired a resource, it will continue to consume that resource without relinquishing its demand. This prevents other threads from fully utilizing the resources, resulting in wasted computing power. Coroutines, unlike threads, can "friendly" share computing resources. When a coroutine's execution state is interrupted, it automatically relinquishes its demand for computing resources (this can be described as a coroutine actively suspending itself after an interruption), without affecting other coroutines' use of the resources, thus improving resource utilization.

[0031] Furthermore, to prevent coroutines from demanding unlimited computing resources, coroutines need to be grouped, and each coroutine group needs to be configured with a corresponding upper limit on the computing resources it can consume. The process needs to create several scheduling threads to manage the scheduling of computing resources. These threads can schedule computing resources for a coroutine only if they determine that the total amount of computing resources consumed by the coroutine group to which it belongs has not exceeded the limit.

[0032] Furthermore, in cloud computing scenarios, processes can be deployed in virtual machines, virtual machines can be deployed in virtual machine containers on cloud computing servers, or they can be deployed directly on cloud computing servers. By adopting the above technical solutions, it is possible to manage computing resources without using cgroup technology, without relying on cgroup controllers for thread switching operations, without involving switching between kernel mode and user mode, and without consuming additional computing resources. Moreover, under the cgroup mechanism, the controller typically does not track the computing resources consumed by worker thread groups, but rather manages them based on the upper limit of the resources that each worker thread group can consume, resulting in insufficient fine-grained control. With the above technical solutions, because coroutines automatically suspend themselves after their execution is interrupted, automatically stopping the consumption of computing resources, it is very convenient to track and record the amount of computing resources consumed by coroutines, achieving fine-grained control over the computing resource consumption of coroutine groups.

[0033] The above technical solution will be described in detail below with reference to the accompanying drawings.

[0034] Figure 1 This is a flowchart illustrating a processor computing resource scheduling method provided in this specification, including the following steps:

[0035] S100: Any working coroutine in the coroutine group enters the ready queue.

[0036] Figure 1 The method flow shown can be applied to processes running on computing devices. These processes can be those deployed on computing devices by users to perform their own business computing.

[0037] A process can create several worker coroutine groups and several scheduling threads, wherein each worker coroutine group comprises at least two worker coroutines. Each coroutine group can correspond to a maximum limit of consuming computing resources.

[0038] Users can flexibly configure the worker coroutines created by the process, the division of coroutine groups, and the upper limit of consuming computing resources corresponding to each coroutine group through the coroutine group configuration interface exposed by the process. In some embodiments, users can divide worker coroutine groups according to the different computing tasks that the process needs to perform. Each computing task corresponds one-to-one with each worker coroutine group, and the computing task is jointly implemented by each worker coroutine in its corresponding worker coroutine group.

[0039] In other words, the process exposes a coroutine group configuration interface to the user. In response to a user's input of a coroutine group update command via the configuration interface, the process updates the worker coroutines contained in one or more created worker coroutine groups, and / or adjusts the maximum consuming computing resources corresponding to the one or more created worker coroutine groups.

[0040] In other embodiments, users can assign a subset of work coroutine groups to each computational task. Additionally, users can designate another subset of work coroutine groups as higher-level permission groups. Work coroutines in these higher-level permission groups can be used to implement different computational tasks or the same computational task. The nature of higher-level permission groups will not be discussed here but will be described in detail later.

[0041] The computing resources of a processor can typically be the available time of each processor core. The upper limit of the consuming computing resources for each work coroutine group includes: the upper limit of the proportion of the available time of a processing core that can be allocated to that work coroutine group.

[0042] In some embodiments, processes can be deployed in virtual machines, either directly on a cloud computing server or within a virtual machine container on a cloud computing server. In these embodiments, the available time of a virtual processing core of the virtual machine; the upper limit of consuming computing resources corresponding to each worker coroutine group includes: an upper limit on the proportion of available time from a virtual processing core allocated to that worker coroutine group.

[0043] In some embodiments, the maximum amount of computing resources that can be consumed by each work coroutine group is directly related to the fee paid by the user for that work coroutine group. For example, in a cloud computing scenario, the maximum amount of computing resources that can be consumed by each work coroutine group is directly related to the fee paid by the user to the cloud computing service provider for that work coroutine group.

[0044] Typically, a work coroutine can enter the ready queue after it has reached a ready state.

[0045] It's important to clarify here that a coroutine's ready execution state can be understood as having no restrictions on its I / O, timer, or concurrency synchronization mechanisms. This means the coroutine can continue executing its task. Conversely, a coroutine's interrupted execution state can be understood as having at least one limitation in its I / O, timer, or concurrency synchronization mechanisms. This means the coroutine cannot continue executing its task and therefore cannot consume further computing resources. In this case, the computing resources occupied by the coroutine are idle, and the scheduling thread needs to allocate these idle resources to other coroutines that are ready for execution.

[0046] In other words, the execution status of the worker coroutine is ready, which can be understood as including: the worker coroutine has obtained the necessary execution parameters input by the user; the worker coroutine has determined that it has reached the next pre-planned execution time point; and the worker coroutine has determined that the concurrent lock restricting its current reading / writing of data from storage has been released.

[0047] The interruption of the execution status of this worker coroutine can include two possibilities. One possibility is that the worker coroutine is forcibly stopped by the process, and will not subsequently reach a ready execution status. The other possibility is that the worker coroutine is suspended because some execution conditions are not met; when these conditions are met later, it can be considered ready and can resume execution. The suspension of worker coroutine execution can include: the worker coroutine has not yet obtained the necessary execution parameters input by the user; or the worker coroutine determines that the next pre-planned execution time has not yet arrived; or the worker coroutine determines that there is a concurrent lock restricting its current read / write operations from storage.

[0048] S102: The scheduling thread reads a work coroutine from the ready queue and determines whether the read work coroutine meets the scheduling conditions; if the determination result is yes, then step S104 is executed; if the determination result is no, then step S106 is executed.

[0049] In some embodiments, a process can create at least two scheduling threads, each used to schedule different sets of computing resources on the processor. In a cloud computing scenario, different scheduling threads can manage different virtual cores; for example, each scheduling thread can correspond one-to-one with each virtual core. The scheduling threads can read worker coroutines from the ready queue based on a load balancing mechanism.

[0050] The scheduling condition for a work coroutine is met when the total amount of computing resources consumed by the work coroutine group to which the work coroutine belongs does not exceed the upper limit of the computing resources that can be consumed by the work coroutine group.

[0051] S104: The scheduling thread provides resource scheduling for this worker coroutine.

[0052] A scheduling thread can offer itself to worker coroutines for use, allowing the scheduling thread to allocate computing resources to those worker coroutines. In some embodiments, a scheduling thread can be occupied by only one worker coroutine. In other embodiments, a scheduling thread can be occupied by multiple worker coroutines, and within the scope of its own schedulable computing resources, the scheduling thread allocates computing resources to these multiple worker coroutines based on a preset strategy.

[0053] S106: The scheduling thread refuses to provide resource scheduling for the worker coroutine.

[0054] If a worker coroutine is refused scheduling computing resources by the scheduling thread, it is equivalent to the scheduling thread refusing to provide itself to the worker coroutine for use, and the worker coroutine can withdraw its request for computing resources.

[0055] In some embodiments, a process (e.g., a scheduling thread or an accumulation thread created by the process specifically for accumulating the total amount of computing resources consumed by each work goroutine group) can periodically or irregularly re-accumulate the total amount of computing resources consumed by each work goroutine group. That is, the total amount of computing resources consumed by each work goroutine group can be periodically or irregularly reset to zero. In this case, if the total amount of computing resources consumed by the work goroutine group has already exceeded the upper limit before re-accumulation, then after re-accumulation, the work goroutines in the work goroutine group can again meet the scheduling conditions.

[0056] In some embodiments, if a worker coroutine is refused scheduling computing resources by the scheduled thread, the worker coroutine can suspend itself and wait until the total amount of computing resources consumed by the worker coroutine group to which it belongs is cleared in the cumulative count before entering the ready queue.

[0057] In some embodiments, if the scheduling thread refuses to offer itself to the worker coroutine for use, it creates a timer and binds it to the worker coroutine; wherein, the timer's duration is the time elapsed from the current time point until the next recalculation of the total amount of computing resources consumed by the worker coroutine group to which the worker coroutine belongs; after determining that the timer has finished timing, the worker coroutine enters the ready queue.

[0058] S108: If allowed to occupy the scheduling thread, the working coroutine continues to consume the computing resources scheduled by the scheduling thread; and the occupation of the scheduling thread is released after the execution state is interrupted.

[0059] After a coroutine's execution is interrupted, it will automatically suspend itself based on its own characteristics and no longer require computation. This can be understood as a coroutine "voluntarily" ending its occupation of computing resources. This means that the scheduling thread does not need to switch coroutines, and therefore does not need to involve the conversion between kernel mode and user mode, thus avoiding the consumption of additional computing resources. Coroutines can switch between each other automatically in user mode.

[0060] If a coroutine determines that its execution status is ready again, it can enter the ready queue on its own. The scheduling thread can then read the coroutine from the ready queue again and schedule computing resources for the coroutine, provided that the actual computing resources consumed by the coroutine group to which the coroutine belongs have not exceeded the limit.

[0061] In some embodiments, the plurality of worker coroutine groups created by the process include at least one first type of worker coroutine group and at least one second type of worker coroutine group. If the scheduling thread detects that a first type of worker coroutine continuously consumes computing resources, resulting in the failure to meet scheduling conditions, it refuses to offer itself to the first type of worker coroutine for use; if the scheduling thread detects that a second type of worker coroutine continuously consumes computing resources, resulting in the failure to meet scheduling conditions, it continues to offer itself to the second type of worker coroutine for use.

[0062] In other words, the second type of work coroutine group mentioned above can be understood as the work coroutine group with higher permission levels as described above. If a work coroutine in such a work coroutine group continuously consumes computing resources while occupying the scheduling thread, causing the total amount of computing resources consumed by the work coroutine group to exceed the limit, then as long as the execution state of the work coroutine itself is not interrupted, the scheduling thread can continue to over-schedule computing resources for the work coroutine until the execution state of the work coroutine itself is interrupted and it actively suspends itself.

[0063] See Figure 2 , Figure 2 An example of a computing resource scheduling process is provided. Figure 2 As shown, a process running in a virtual machine on a computing device can create three scheduling threads, each responsible for managing the computing resources of one virtual machine core. Each scheduling thread can read worker coroutines from the ready queue to provide virtual machine core computing resources for the read worker coroutines. Worker coroutines continuously consume the computing resources provided by the scheduling threads. If the execution state terminates, the worker coroutine will suspend itself and no longer occupy a scheduling thread. Once the worker coroutine's execution state becomes ready again, it will enter the ready queue, waiting to be read and provided with resources by the scheduling thread.

[0064] This disclosure provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the functions of a process.

[0065] This disclosure also provides a computing device in which a process runs on the computing device, the process creating a plurality of worker coroutine groups and a plurality of scheduling threads; the plurality of worker coroutine groups include at least two worker coroutines;

[0066] Each worker coroutine enters the ready queue after its execution status is ready;

[0067] Each scheduling thread reads a worker coroutine from the ready queue and determines whether the read worker coroutine meets the scheduling conditions. The scheduling conditions include: the total amount of computing resources consumed by the worker coroutine group to which the worker coroutine belongs does not exceed the upper limit of the computing resources that the worker coroutine group can consume. If the determination result is yes, the thread offers itself to the worker coroutine for use so that computing resources can be scheduled for the worker coroutine. If the determination result is no, the thread refuses to offer itself to the worker coroutine for use.

[0068] If the working coroutine occupies the scheduling thread, it will continuously consume the computing resources scheduled by the scheduling thread; and after the execution state is interrupted, it will release the occupation of the scheduling thread and enter the ready queue after the execution state is ready again.

[0069] Figure 3 This is a schematic diagram of the structure of a computing device provided in this disclosure. The computing device 15 may include, but is not limited to, a processor 151, a memory 152, and a bus 153 connecting different system components (including the memory 152 and the processor 151).

[0070] The memory 152 stores computer instructions that can be executed by the processor 151, enabling the processor 151 to perform the methods of any embodiment of this disclosure. The memory 152 may include a random access memory (RAM) 1521, a cache memory 1522, and / or a read-only memory (ROM) 1523. The memory 152 may also include a program tool 1525 having a set of program modules 1524, including but not limited to: an operating system, one or more application programs, other program modules, and program data. One or more combinations of these program modules may include an implementation of a network environment.

[0071] Bus 153 may include, for example, a data bus, an address bus, and a control bus. The computing device 15 can also communicate with external devices 155 via I / O interface 154, such as a keyboard or a Bluetooth device. The computing device 150 can also communicate with one or more networks via network adapter 156, such as a local area network (LAN), a wide area network (WAN), or a public network. As shown, network adapter 156 can also communicate with other modules of the computing device 15 via bus 153.

[0072] Furthermore, although the operations of the methods disclosed herein are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all of the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0073] While the spirit and principles of this disclosure have been described with reference to several specific embodiments, it should be understood that this disclosure is not limited to the disclosed specific embodiments, and the division of aspects does not imply that features in these aspects cannot be combined for benefit; such division is merely for convenience of expression. This disclosure is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.

[0074] The above description is merely a preferred embodiment of the various embodiments of this specification and is not intended to limit the various embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the various embodiments of this specification should be included within the protection scope of the various embodiments of this specification.

Claims

1. A method for computing resource scheduling, applied to a computing device, wherein a process of the computing device creates a plurality of work coroutine groups and a plurality of scheduling threads, and the method comprises: any work coroutine of the coroutine group enters a ready queue; any scheduling thread reads a work coroutine from the ready queue, and determines whether the read work coroutine meets a scheduling condition; wherein the scheduling condition comprises: a total amount of consumed computing resources of a work coroutine group to which the work coroutine belongs does not exceed an upper limit of consumable computing resources corresponding to the work coroutine group; and the upper limit of consumable computing resources corresponding to the work coroutine group is an upper limit of a time proportion allocated to the work coroutine group from available time of a processor core or a virtual processor core; when the determination result is yes, the scheduling thread provides resource scheduling for the work coroutine; and when the determination result is no, the scheduling thread refuses to provide resource scheduling for the work coroutine; if allowed to occupy the scheduling thread, the work coroutine consumes the computing resources scheduled by the scheduling thread, and releases the occupation of the scheduling thread after the execution state is interrupted. 2.The method of claim 1, further comprising: the process periodically or aperiodically re-accumulates the total amount of consumed computing resources of each work coroutine group. 3.The method of claim 2, further comprising: if the scheduling thread refuses to provide resource scheduling for the work coroutine, the scheduling thread creates a timer and binds the timer to the work coroutine; wherein a timing duration of the timer is a time duration from a current time point to a time point at which the total amount of consumed computing resources of the work coroutine group to which the work coroutine belongs is next re-accumulated; the work coroutine enters the ready queue after determining that the timer finishes timing. 4.The method of claim 1, after the execution state of the work coroutine is interrupted, further comprising: the work coroutine enters the ready queue after the execution state is ready.

5. The method of claim 1, wherein, the plurality of work coroutine groups created by the process comprises at least one first-type work coroutine group and at least one second-type work coroutine group; and the method further comprises: if the scheduling thread monitors that the first-type work coroutine continuously consumes computing resources to cause the scheduling condition not to be met, the scheduling thread refuses to provide resource scheduling for the first-type work coroutine; if the scheduling thread monitors that the second-type work coroutine continuously consumes computing resources to cause the scheduling condition not to be met, the scheduling thread continues to provide resource scheduling for the second-type work coroutine until the execution state of the second-type work coroutine is interrupted.

6. The method of claim 1, wherein, the upper limit of consumable computing resources corresponding to each work coroutine group is positively correlated with a fee paid by a user for the work coroutine group.

7. The method of claim 1, wherein, the plurality of scheduling threads comprises at least two scheduling threads, and different scheduling threads are used to schedule different sets of computing resources of a processor; the reading of the work coroutine from the ready queue by any scheduling thread comprises: the reading of the work coroutine from the ready queue by any scheduling thread is based on a load balancing mechanism between the scheduling thread and other scheduling threads.

8. The method of claim 1, wherein, the execution state of the work coroutine being ready comprises: the work coroutine currently acquires an execution necessary parameter input by a user; and the work coroutine determines that a next execution time point scheduled in advance is currently reached; and the work coroutine determines that a concurrent lock limiting the work coroutine from currently reading / writing data from the storage is released; the execution state of the work coroutine is interrupted, including: the work coroutine currently does not acquire an execution necessary parameter input by a user; or the work coroutine determines that the next execution time point scheduled in advance is not currently reached; or the work coroutine determines that the concurrent lock limiting the work coroutine from currently reading / writing data from the storage exists.

9. The method of claim 1, wherein, the process exposes a coroutine group configuration interface to a user; the method further includes: the process updates the work coroutine included in the created one or more work coroutine groups and / or adjusts the upper limit of the consumable computing resource corresponding to the created one or more work coroutine groups in response to the coroutine group update instruction input by the user when invoking the configuration interface.

10. The method of claim 1, wherein, the process runs in a virtual machine, and the virtual machine is deployed on the computing device; the computing resource scheduled by the scheduling thread includes available time of a virtual processing core of the virtual machine; and the upper limit of the consumable computing resource corresponding to each work coroutine group includes a time proportion upper limit allocated to the work coroutine group from the available time of the virtual processing core. 11.A computing device, comprising a memory and a processor; the memory is configured to store computer instructions executable on the processor; and the processor is configured to implement the method in any one of claims 1-10 when executing the computer instructions. 12.A computer readable storage medium, having stored thereon a computer program, the program being executed by a processor to implement the method in any one of claims 1-10.

Images