A method, system, device, and storage medium for scheduling and management of a coroutine pool.

Abstract

The application discloses a kind of coroutine pool scheduling management method, system, device and storage medium.The method creates corresponding coroutine task according to the service demand of application program;Then, the coroutine pool of host thread is established and initialized;Subsequently, the host thread is controlled to obtain hosting core, to start the host thread;And the coroutine task in the host thread is executed by task scheduling function.The method generates corresponding coroutine task according to the service demand of application program, and allocates hosting core for host thread according to coroutine task, can effectively distinguish the demand of different data processing tasks, implement more targeted and more fine-grained coroutine scheduling and execution control, realize the isolation of host thread and non-host thread, implement differentiated scheduling control, for multi-core processor architecture, realize the global unified resource allocation management of multiple coroutine pool.The application can be widely applied in the field of communication technology.

Description

Technical Field

[0001] This invention relates to the field of communication technology, and in particular to a method, system, device, and storage medium for managing a coroutine pool. Background Technology

[0002] In related technologies, in order to enable data center services to provide high-concurrency, low-latency processing responses, a coroutine pool can be created, in which different coroutines in the coroutine pool handle data tasks. However, in a multi-core processor architecture system, the scheduling and management of the coroutine pool is much more complex than that of the thread pool, making it impossible to efficiently allocate and manage the coroutine pool.

[0003] In summary, the problems with the relevant technologies urgently need to be addressed. Summary of the Invention

[0004] The purpose of this invention is to at least partially solve one of the technical problems existing in the prior art.

[0005] Therefore, one objective of this invention is to provide a coroutine pool scheduling management method, system, apparatus, and medium that can achieve rapid response to I / O service requests.

[0006] To achieve the above-mentioned technical objectives, the technical solutions adopted in the embodiments of the present invention include:

[0007] On one hand, embodiments of the present invention provide a method for scheduling and managing a coroutine pool, comprising the following steps:

[0008] Create corresponding coroutine tasks based on the application's service requirements;

[0009] Establish and initialize the coroutine pool for the host thread;

[0010] Control the host thread to acquire the managed core and start the host thread;

[0011] The coroutine task within the host thread is executed through the task scheduling function.

[0012] Furthermore, after the step of executing the coroutine task within the host thread through the task scheduling function, the following steps are also included:

[0013] Once the host thread has finished running, reclaim the managed core.

[0014] Furthermore, the step of creating corresponding coroutine tasks based on the application's service requirements specifically includes:

[0015] Based on the service requirements of the application, obtain the creation type of the coroutine task;

[0016] Based on the creation type, obtain the corresponding managed core set;

[0017] Based on the managed core set, create coroutine tasks.

[0018] Furthermore, the step of creating a coroutine task based on the managed core set specifically includes:

[0019] The target coroutine pool is determined within the managed core set;

[0020] Create a coroutine task on the target coroutine pool.

[0021] Furthermore, the step of initializing the host thread's coroutine pool specifically includes:

[0022] Initialize the state of each coroutine in the coroutine pool;

[0023] Set the return address in the stack space of each coroutine to the address of the task scheduling function.

[0024] Furthermore, the step of controlling the host thread to acquire the managed core specifically includes:

[0025] The required number of logical cores is determined based on the service requirements of the application.

[0026] Request managed cores based on the number of logical cores.

[0027] Furthermore, the step of executing the coroutine task within the host thread through the task scheduling function specifically includes:

[0028] Traverse the coroutine pool to obtain the target coroutine in the coroutine pool;

[0029] Switch the context of the target coroutine;

[0030] The coroutine task is executed in the stack space of the target coroutine.

[0031] On the other hand, embodiments of the present invention propose a coroutine pool scheduling and management system, including:

[0032] The first module is used to create corresponding coroutine tasks based on the service requirements of the application.

[0033] The second module is used to create and initialize the coroutine pool for the host thread;

[0034] The third module is used to control the host thread to acquire the managed core and start the host thread;

[0035] The fourth module is used to execute coroutine tasks within the host thread through a task scheduling function.

[0036] On the other hand, embodiments of the present invention provide a coroutine pool scheduling and management device, comprising:

[0037] At least one processor;

[0038] At least one memory for storing at least one program;

[0039] When the at least one program is executed by the at least one processor, the at least one processor implements the coroutine pool scheduling management method.

[0040] On the other hand, embodiments of the present invention provide a storage medium storing processor-executable instructions, which, when executed by a processor, are used to implement the aforementioned coroutine pool scheduling and management method.

[0041] This invention discloses a method for scheduling and managing a coroutine pool, which has the following beneficial effects:

[0042] This embodiment creates corresponding coroutine tasks based on the service requirements of the application; then, it establishes and initializes a coroutine pool for the host thread; subsequently, it controls the host thread to acquire managed cores to start the host thread; and finally, it executes the coroutine tasks within the host thread through a task scheduling function. This method, by generating corresponding coroutine tasks based on the application's service requirements and allocating managed cores to the host thread based on the coroutine tasks, can effectively differentiate the needs of different data processing tasks, implement more targeted and finer-grained coroutine scheduling and execution control, and achieve isolation between host threads and non-host threads without affecting the operating system's own scheduling mechanism. It implements differentiated scheduling control and, for multi-core processor architectures, achieves globally unified resource allocation management across multiple coroutine pools. Attached Figure Description

[0043] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following description is provided with accompanying drawings of the relevant technical solutions in the embodiments of the present invention or the prior art. It should be understood that the accompanying drawings described below are only for the purpose of clearly illustrating some embodiments of the technical solutions of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort.

[0044] Figure 1 A schematic diagram illustrating the implementation environment of a coroutine pool scheduling and management method provided in an embodiment of the present invention;

[0045] Figure 2 A flowchart illustrating a coroutine pool scheduling and management method provided in an embodiment of the present invention;

[0046] Figure 3This is a schematic diagram of the structure of a coroutine pool scheduling and management system provided in an embodiment of the present invention;

[0047] Figure 4 This is a schematic diagram of a coroutine pool scheduling and management device provided in an embodiment of the present invention. Detailed Implementation

[0048] This section will describe in detail specific embodiments of the present invention. Preferred embodiments of the present invention are shown in the accompanying drawings. The purpose of the drawings is to supplement the textual description with graphics, so that people can intuitively and vividly understand each technical feature and overall technical solution of the present invention, but they should not be construed as limiting the scope of protection of the present invention.

[0049] In the description of the embodiments of the present invention, "several" means one or more, "multiple" means two or more, "greater than," "less than," "exceeding," etc. are understood to exclude the number itself, while "above," "below," "within," etc. are understood to include the number itself. "At least one" refers to one or more, and "at least one of the following" and similar expressions refer to any combination of these items, including any combination of single or multiple items. If "first," "second," etc., are used in the description, they are only for the purpose of distinguishing technical features and should not be construed as indicating or implying relative importance or implicitly indicating the number of indicated technical features or the order of the indicated technical features.

[0050] It should be noted that the terms "setting," "installing," and "connecting" in the embodiments of this invention should be interpreted broadly. Those skilled in the art can reasonably determine the specific meaning of the above terms in the embodiments of this invention in conjunction with the specific content of the technical solution. For example, the term "connection" can be a mechanical connection, an electrical connection, or a connection that allows for mutual communication; it can be a direct connection or an indirect connection through an intermediate medium.

[0051] In the description of the embodiments of the present invention, the references to "one embodiment / implementation," "another embodiment / implementation," or "some embodiments / implementations," "in the above embodiments / implementations," etc., refer to specific features, structures, materials, or characteristics described in connection with embodiments or examples that are included in at least two embodiments or implementations of this disclosure. In this disclosure, the illustrative expressions of the above terms do not necessarily refer to the same illustrative embodiment or implementation. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or implementations.

[0052] It should be noted that the technical features involved in the various embodiments of the present invention described below can be combined with each other as long as they do not conflict with each other.

[0053] In related technologies, coroutine pooling is commonly used to meet users' demands for low-latency responses. Generally, when a backend business server system handles high-concurrency service requests, a coroutine pool can be pre-created to reduce performance fluctuations caused by frequently starting / stopping a large number of coroutines. Each coroutine corresponds to a data processing task, and coroutines are then retrieved / returned from the pool. This process requires efficient allocation and management of the coroutine pool.

[0054] However, the existing coroutine pool scheduling management still has the following three shortcomings:

[0055] First, the existing coroutine scheduling mechanism does not differentiate between different types of coroutines. Each coroutine corresponds to a data processing task, and different data processing tasks have different real-time and performance requirements. The existing coroutine scheduling mechanism treats all coroutines uniformly, which inevitably leads to a rigid scheduling and management method that is difficult to adapt to the needs of different data processing tasks.

[0056] Secondly, the scheduling mechanism of coroutines is difficult to effectively isolate from the operating system's thread scheduling mechanism. A coroutine is a user-mode thread, a time-sharing technology for kernel threads. Coroutines are transparent to the operating system, and the operating system's thread scheduling mechanism cannot identify the kernel thread (i.e., the "host thread") where the coroutine resides. This makes it impossible to effectively distinguish the execution timing of the host thread from that of non-host threads, resulting in the coroutine's execution timing and efficiency still being affected by the operating system's thread scheduling mechanism, making effective isolation difficult.

[0057] Third, the scheduling mechanism of coroutines is difficult to unify resource allocation and management among multiple host threads. Kernel threads are the carriers of coroutines, and the scheduling mechanism of coroutines can only control the execution time of coroutines within a single host thread. However, in a multi-core processor architecture, each logical core can run a host thread, and each host thread can carry a coroutine pool. The lack of a unified resource allocation and management mechanism among multiple coroutine pools inevitably restricts the efficiency and performance improvement of coroutine pools in a multi-core processor architecture.

[0058] To address this, this application proposes a coroutine pool scheduling management method, system, device, and storage medium. The method includes creating corresponding coroutine tasks based on the service requirements of an application; then, establishing and initializing a coroutine pool for the host thread; subsequently, controlling the host thread to acquire a managed core to start the host thread; and finally, executing the coroutine tasks within the host thread through a task scheduling function. This method, by generating corresponding coroutine tasks based on the application's service requirements and allocating managed cores to the host thread based on the coroutine tasks, can effectively differentiate the needs of different data processing tasks, implement more targeted and finer-grained coroutine scheduling and execution control, and achieve isolation between host threads and non-host threads without affecting the operating system's own scheduling mechanism. It also enables differentiated scheduling control and, for multi-core processor architectures, achieves globally unified resource allocation management across multiple coroutine pools.

[0059] Reference Figure 1 , Figure 1 This embodiment of the application provides a schematic diagram of the implementation environment for a coroutine pool scheduling and management method. The main hardware and software components of this implementation environment include a logical core scheduling module 101 and a coroutine pool task scheduling module 102. Specifically, the logical core scheduling module allocates and reclaims logical cores and schedules and isolates host threads according to the core requirements of the coroutine application. It is responsible for managing the logical cores of the system, allocating and reclaiming logical cores for host threads, and scheduling and controlling the execution of host threads.

[0060] The logical kernel scheduling module 101 defines "managed kernels" and "unmanaged kernels." "Managed kernels" are logical kernels managed by the logical kernel scheduling module 101, which allocates and reclaims them. "Unmanaged kernels" are kernels not managed by the logical kernel scheduling module but are managed by the operating system. Host threads are scheduled by the logical kernel scheduling module, which can schedule a target host thread to run on a "managed kernel," or, when available "managed kernels" are scarce, schedule a target host thread to run on an "unmanaged kernel." Non-host threads all run on "unmanaged kernels." Kernel threads running on "unmanaged kernels," including both host and non-host threads, are scheduled by the operating system. This achieves isolation between host and non-host threads.

[0061] The logical core scheduling module 101 also defines a "managed core preemption" event and a timer. The "managed core preemption" event means that the logical core scheduling module 101 schedules the current host thread on the managed core to run on an unmanaged core, thereby reclaiming the managed core and reallocating it to other host threads. When the timer expires, the "managed core preemption" event is triggered.

[0062] The logical core scheduling module 101 also defines four states for the host thread: "Initial State," "Running State," "Blocked State," and "Preemptive State." "Initial State" means that the host thread has just established a connection with the service process and has not yet run on a managed core. "Running State" means that the host thread has successfully requested a managed core from the logical core scheduling module and is running on that managed core. "Blocked State" means that the host thread has not yet acquired a managed core and is waiting to be allocated one, or the host thread has previously successfully requested a managed core but is not currently running on that managed core and is in a paused state. "Preemptive State" means that the host thread previously ran on a managed core, but that managed core was preempted by another host thread, and the thread has been moved to an unmanaged core to run. The preferred command for a host thread in a "preemptive state" is to be scheduled back to the managed core it last ran on. That is, when the managed core of a host thread is reclaimed, the host thread will be marked as "preemptive" and will be rescheduled back to the managed core it last ran on. Only when the managed core that the host thread in the "preemptive state" last ran on is still occupied will the host thread in the "preemptive state" be scheduled to run on another available managed core.

[0063] The coroutine pool task scheduling module 102 provides a globally unified scheduling and management function for multiple coroutine pools on a multi-core processor architecture. The coroutine pool task scheduling module defines two coroutine states: "occupied state" and "idle state." An "occupied state" coroutine means that it has been assigned to a coroutine task, and the address of the predefined task processing function and its parameter addresses can be found through this coroutine; an "idle state" coroutine means that it has not yet been assigned to a coroutine task.

[0064] The logical core scheduling module 101 provides the allocation of underlying processor resources and the scheduling isolation function of host threads. It allocates available logical cores to each coroutine application, and then schedules and manages each host thread to meet the core requirements of each coroutine application to the greatest extent and controls the execution of each host thread.

[0065] The execution flow of the logical core scheduling module 101 includes: entering the corresponding processing flow according to the state of the host thread, allocating available logical cores to each coroutine application and scheduling the execution of each host thread in real time, controlling the running state and execution timing of each host thread, and periodically reclaiming idle core resources.

[0066] The coroutine pool task scheduling module 102 provides a global unified scheduling and management function for multiple coroutine pools on a multi-core processor architecture. It can create "exclusive coroutine tasks" and "shared coroutine tasks", provides a dynamic adjustment mechanism for logical core resources, realizes global unified scheduling control of coroutine tasks among coroutine pools of multiple logical cores, and realizes the free scaling of coroutine tasks.

[0067] The execution flow of the coroutine pool task scheduling module 102 includes: creating different types of coroutine tasks in the coroutine pool, selecting a coroutine pool for the coroutine task, scheduling the coroutine task in the coroutine stack space, coroutine migration between multiple coroutine pools, and maintaining the state of the coroutine pool.

[0068] It should be noted that the embodiments of this application only provide a portion of the modules of the implementation environment of the coroutine pool scheduling management method. The implementation environment of the coroutine pool scheduling management method may also include other modules to achieve the corresponding functions, and no specific limitation is made.

[0069] Figure 2 This is a flowchart of a coroutine pool scheduling and management method provided in an embodiment of this application. Figure 2 A coroutine pool scheduling and management method is configured in such a way as Figure 1 The implementation environment shown is used as an example for illustration. (Refer to...) Figure 2 The goroutine pool scheduling and management method includes, but is not limited to, steps S110 to S140.

[0070] Step S110: Create corresponding coroutine tasks based on the service requirements of the application.

[0071] In this step, it is necessary to obtain the application's service requirements in order to create corresponding coroutine tasks. It is understood that the application's service requirements will change according to the user's needs, resulting in different computer resources required for each service requirement. For example, in some embodiments, an application's service requirement needs to run on a dedicated logical core, while other service requirements can share a logical core with other service requirements. To distinguish between different service requirements, the coroutine pool task scheduling module 102 also defines two types of coroutine tasks: "shared coroutine tasks" and "exclusive coroutine tasks." A coroutine pool on a managed core can accommodate multiple "shared coroutine tasks" simultaneously; this type of managed core is called a "shared managed core." An "exclusive coroutine task" completely occupies a managed core; the coroutine pool contains only this one coroutine and cannot accommodate any other coroutine tasks; this type of managed core is called an "exclusive managed core." "Shared coroutine tasks" can be "migrated" to other "shared managed cores" for execution, while "exclusive coroutine tasks" will occupy an "exclusive managed core" until execution is complete. When a coroutine application needs to create exclusive coroutine tasks due to business requirements, but exclusive managed cores are scarce, all shared coroutine tasks on a shared managed core can be added to the coroutine pool of another shared managed core. This transforms the shared managed core into an exclusive managed core, meeting the application's needs. Conversely, when coroutine tasks on an exclusive managed core finish executing and become idle, the core can be converted back to a shared managed core. This dynamic adjustment mechanism for logical core resources allows coroutine applications to scale freely as needs change.

[0072] Step S120: Establish and initialize the coroutine pool for the host thread.

[0073] In this step, a coroutine pool needs to be created for the host thread running for the first time, to run the application coroutine tasks described earlier. Specifically, a process is a startup instance of an application. For example, opening a piece of software starts a process. A thread, belonging to a process, is the actual executor of the program. A process contains at least one main thread and can have more child threads; each thread has its own stack space. Coroutines are a more lightweight concept than threads. Just as a process can have multiple threads, a thread can have multiple coroutines. Most importantly, coroutines are not managed by the operating system kernel but are entirely controlled by the program (i.e., executed in user mode). This results in significantly improved performance, as it avoids the resource consumption associated with thread switching.

[0074] Step S130: Control the host thread to acquire the managed core and start the host thread.

[0075] In this step, managed cores need to be allocated to the host thread to start it. Specifically, the coroutine application notifies the logical core scheduling module of the number of logical cores required, and then each host thread of the coroutine application also requests a managed core from the logical core scheduling module. Once the host thread successfully obtains a managed core, it enters the "running state".

[0076] Step S140: Execute the coroutine task within the host thread through the task scheduling function.

[0077] In this step, after the host thread successfully obtains the managed core, the task scheduling function runs in the coroutine stack space, scheduling and executing all coroutine tasks in this coroutine pool. The coroutine task scheduling process is to select the target coroutine, perform a switch from the current coroutine context environment to the target coroutine context environment, and execute the coroutine task in the target coroutine's stack space.

[0078] As a further optional implementation, after the step of executing the coroutine task within the host thread through the task scheduling function, the following steps are also included:

[0079] Once the host thread has finished running, reclaim the managed core.

[0080] Specifically, before terminating, each host thread releases its respective coroutine pool resources. The logical core scheduling module then reclaims the corresponding managed cores for reallocation and executes the "managed core allocation and host thread scheduling" function. Finally, the logical core scheduling module terminates its operation when all coroutine applications have finished running.

[0081] The workflow of the "Managed Core Allocation and Host Thread Scheduling" function is as follows:

[0082] P1. Define a queue of host threads that have been allocated a managed core, also known as a "ready" host thread queue. Each host thread in the queue is in the "running state" and the managed core where each host thread is located has not registered a "managed core preemption" event. The queue is initialized to empty.

[0083] P2. Define a host thread queue that "needs to be allocated managed cores", also known as the "prepared" host thread queue. Each host thread in the queue is in a "blocked state" or a "preemptive state". The queue is initialized to empty.

[0084] P3. Traverse the global "running" queue and construct the "ready" host thread queue.

[0085] The process of constructing the "ready" host thread queue in step P3 includes the following steps:

[0086] Iterate through each host thread in the global "run" queue.

[0087] Get the coroutine application corresponding to each host thread. If the number of managed cores already allocated to the coroutine application is less than the number of cores required, add the host thread to the end of the "ready" host thread queue and increment the number of managed cores already allocated to the coroutine application by 1.

[0088] Determine if the sum of the number of elements in the "Prepared" host thread queue and the number of elements in the "Ready" host thread queue equals the total number of managed cores. If yes, it means there are no extra managed cores available for allocation, and the process ends. If no, it means there are still extra managed cores available for allocation, and the next host thread in the global "Run" queue is selected until the traversal is complete.

[0089] P4. Traverse all coroutine applications and construct a "prepared" host thread queue.

[0090] Step P4, the process of constructing and "preparing" the host thread queue, includes the following steps:

[0091] Select a coroutine application that requires managed cores in a Round Robin manner (i.e., the number of managed cores already allocated to the coroutine application is less than its required number of cores).

[0092] Determine if the number of host threads belonging to the coroutine application and in a "preemptive" state is 0. If it is 0, select a host thread, add it to the end of the "prepared" host thread queue, and increment the "number of managed cores already allocated to the coroutine application" by 1, indicating that a managed core has been allocated to the host thread.

[0093] If the coroutine application does not have a host thread in a "preemptive" state, then it checks if the number of host threads belonging to the coroutine application and in a "blocked" state is 0. If it is 0, then a host thread is selected, added to the end of the "prepared" host thread queue, and the "number of managed cores already allocated to the coroutine application" is incremented by 1, indicating that a managed core has been allocated to the host thread.

[0094] Determine if the sum of the number of elements in the "Prepared" host thread queue and the number of elements in the "Ready" host thread queue equals the total number of managed cores. If yes, it indicates that there are no extra managed cores available for allocation, and the process ends. If no, it indicates that there are still extra managed cores available for allocation, and the next process is selected in a Round Robin manner until all coroutine applications have been traversed.

[0095] P5. Calculate the number of managed cores that need to be allocated. This number is equal to the number of elements in the "prepared" host thread queue plus the number of elements in the "ready" host thread queue.

[0096] P6. Based on the calculated number of managed cores that need to be allocated, dynamically adjust the global "allocated managed cores" set and the global "unallocated managed cores" set.

[0097] The process of dynamically adjusting the global "allocated managed cores" set and the global "unallocated managed cores" set in step P6 includes the following steps:

[0098] Determine if the number of managed cores to be allocated is greater than the number of elements in the global "allocated managed cores" set. If the result is greater, it means that the current global "allocated managed cores" set cannot meet the number of managed cores required by the coroutine application, and more managed cores need to be allocated to meet the requirements. Then, select managed cores from the "unallocated managed cores" set until the number meets the application's needs.

[0099] All selected managed cores are removed from the "Unallocated Managed Cores" set and added to the "Allocated Managed Cores" set. These two sets change dynamically as managed cores are allocated; at any given time, the number of elements in the "Allocated Managed Cores" set plus the number of elements in the "Unallocated Managed Cores" set equals the total number of managed cores.

[0100] P7. Divide the global set of "allocated managed cores" into two subsets: one is the subset of "available managed cores", and the other is the subset of "preemptible managed cores".

[0101] The subset partitioning process in step P7 includes the following steps:

[0102] Define a subset of “available managed cores”, initialized to empty; define a subset of “preemptible managed cores”, initialized to empty.

[0103] Iterate through the global set of "allocated managed cores". Exit this process once the iteration is complete.

[0104] Determine if a host thread is currently running on each managed core. If the managed core is not occupied by a host thread, add the managed core to the subset of "available managed cores".

[0105] If the managed core is already occupied by a host thread, then determine whether the host thread is in the "ready" host thread queue. If not, it means that the managed core is preemptible, and then add the managed core to the "preemptible managed cores" subset.

[0106] In other cases, keeping the subsets of "available managed cores" and "preemptible managed cores" unchanged indicates that each managed core in the current global set of "allocated managed cores" is already occupied by the host thread and cannot be preempted.

[0107] P8. Resume execution of preempted host threads that can be restored to their original managed cores. Allocate the managed core where the preempted host threads in the "prepared" host thread queue last ran to the managed cores, and restore these preempted host threads to run on their original managed cores.

[0108] Step P8, which involves resuming the execution of preemptive threads that can be restored to their original managed core, includes the following steps:

[0109] Iterate through each host thread in the "Prepared" host thread queue, which contains host threads in the "Preempted" and "Blocked" states. Identify the host thread in the "Preempted" state and retrieve the managed kernel where that host thread last ran. Continue this process until all iterations are complete, then end the process.

[0110] Determine if the managed core is in the subset of "available managed cores". If it is, it means that the managed core is currently idle and not occupied by other host threads. The preempted host thread can be restored to this managed core to continue running.

[0111] This managed core is allocated to the currently traversed host thread, completing one core allocation for the host thread.

[0112] Use the logical kernel binding mechanism provided by the operating system to bind and run this host thread on this managed kernel.

[0113] Update the host thread's state from "preempted" to "running" and add it to the global "running" queue. This completes one scheduling and execution of a host thread in a "preempted" state.

[0114] Finally, remove this managed core from the "Available Managed Cores" subset and remove this host thread from the "Ready" host thread queue. Then select the next host thread, find the host thread in the "Preemptive" state, and retrieve the managed core where that host thread last ran. Continue until the traversal is complete.

[0115] If this managed core is not in the subset of "Available Managed Cores", remove this host thread from the "Prepared" host thread queue, then select the next host thread, find the host thread in the "Preempted" state, and obtain the managed core where that host thread last ran. Continue until the traversal is complete.

[0116] P9. Continue allocating managed cores and scheduling execution for the other host threads in the "Prepared" host thread queue. At this point, the host threads in this queue fall into two states: first, host threads in a "preemptive state," but the managed core where these host threads last ran has been occupied by other host threads, and these host threads cannot be resumed to run on their original managed cores; second, host threads in a "blocked state." Allocate available managed cores and schedule execution for host threads in both states.

[0117] Step P9 continues the process of allocating managed cores and scheduling execution for other host threads in the "prepared" host thread queue, including the following steps:

[0118] Iterate through the "prepared" host thread queue, and for each host thread, obtain the ID number of its corresponding coroutine application.

[0119] Identify all preemptive host threads (including the current host thread) within the coroutine application. Then, find the managed cores where each host thread last ran, forming a "reserved managed cores" set. Managed cores in the "reserved managed cores" set are not allocated (because these managed cores are reserved for the preemptive host threads to resume use). The "reserved managed cores" set is empty when the coroutine application does not contain any preemptive host threads.

[0120] If a managed core not in the "Reserved Managed Cores" set can be found in the "Available Managed Cores" subset, and no such managed core can be found, it indicates that no suitable managed core is available for allocation, and the process will exit.

[0121] If such a managed core is found, it is used for allocation. This managed core is allocated to the currently traversed host thread, completing a core allocation for the host thread.

[0122] Determine whether the current host thread in the "prepared" host thread queue is in a "preemptive" state. If so, use the logical kernel binding mechanism provided by the operating system to bind and run this host thread on this managed kernel.

[0123] Update the state of this host thread to "running" and add it to the global "running" queue. This completes one scheduling and execution of a host thread in a "preemptive" state.

[0124] Remove this managed core from the subset of "Available Managed Cores" and remove this host thread from the "Prepared" host thread queue. Then, obtain the ID number of the coroutine application corresponding to the host thread and iterate through the next host thread in the "Prepared" host thread queue.

[0125] If the current host thread is not in a "preemptive state", then the host thread must be in a "blocked state". In this case, the logical kernel binding mechanism provided by the operating system will be used to bind and run this host thread on this managed kernel.

[0126] Update the state of this host thread to "running" and add it to the global "running" queue. This completes one scheduling and execution of a host thread in a "blocked" state.

[0127] Remove this managed core from the subset of "Available Managed Cores" and remove this host thread from the "Prepared" host thread queue. Then, obtain the ID number of the coroutine application corresponding to the host thread and iterate through the next host thread in the "Prepared" host thread queue.

[0128] P10. Traverse the subset of "preemptible managed cores". For each preemptible managed core in the subset, register the "managed core preemption" event and set a timer (default is 10 milliseconds) so that the logical core can detect the "managed core preemption" event.

[0129] As a further optional implementation, the step of creating corresponding coroutine tasks based on the application's service requirements specifically includes:

[0130] Based on the service requirements of the application, obtain the creation type of the coroutine task;

[0131] Based on the creation type, obtain the corresponding managed core set;

[0132] Based on the managed core set, create coroutine tasks.

[0133] Specifically, the creation types of coroutine tasks include "shared coroutine tasks" and "exclusive coroutine tasks." First, the type of coroutine task to be created is determined. If it's a "shared coroutine task," the set of "shared managed cores" for this coroutine application is obtained. If the set is empty, the creation of the "shared coroutine task" fails, and this process ends. If it's not empty, the least loaded managed core is selected from the "shared managed cores" set, meaning the core with the fewest "occupied" coroutines in its coroutine pool is chosen as the coroutine pool for creating the "shared coroutine task." Next, in this coroutine pool, a coroutine with an "idle" state is selected using a round-robin approach. Its stack space is used as the stack space for the coroutine task's runtime, and its state is updated to "occupied." The address of the task processing function and the addresses of its parameters are stored in this coroutine. The "shared coroutine task" creation is complete, and this process ends.

[0134] If it's an "exclusive coroutine task," then obtain the application's "exclusive managed cores" set and "shared managed cores" set. Check if the "exclusive managed cores" set is empty. If not, select a coroutine pool from the "exclusive managed cores" set that hasn't been assigned any coroutine tasks yet. Keep only one "idle" coroutine in this pool, and mark all other coroutines as "occupied," indicating that no other coroutine tasks can be created in this pool. Use the stack space of this single "idle" coroutine as the stack space for the coroutine task's runtime, and update its state to "occupied." Store the address of the task processing function and the addresses of its parameters in this coroutine. Once the "exclusive coroutine task" is created, exit this process.

[0135] When the "Exclusive Managed Cores" set is empty or has no free cores, a managed core is randomly selected from the "Shared Managed Cores" set, removed from the "Shared Managed Cores" set, and added to the "Exclusive Managed Cores" set, becoming a "Exclusive Managed Core" for use. A "Shared Coroutine Task" is created to implement "Coroutine Task Migration," responsible for migrating all coroutine tasks from the selected managed core's coroutine pool to the coroutine pools of other managed cores.

[0136] As a further optional implementation, the step of creating a coroutine task based on the managed core set specifically includes:

[0137] The target coroutine pool is determined within the managed core set;

[0138] Create a coroutine task on the target coroutine pool.

[0139] Specifically, after the host thread requests a managed core, it selects a target coroutine pool from the set of managed cores. The target coroutine pool can be the least loaded managed core, meaning the core with the fewest "occupied" coroutines. This coroutine pool is chosen as the one for creating the "shared coroutine task." Next, within this coroutine pool, a "free" coroutine is selected using a round-robin approach. Its stack space is used as the stack space for the coroutine task's execution, and its status is updated to "occupied." The address of the task processing function and the addresses of its parameters are stored within this coroutine, thus completing the coroutine task creation.

[0140] As a further optional implementation, the step of initializing the host thread's coroutine pool specifically includes:

[0141] Initialize the state of each coroutine in the coroutine pool;

[0142] Set the return address in the stack space of each coroutine to the address of the task scheduling function.

[0143] Specifically, each coroutine in the coroutine pool is initialized to "idle," and the address of the coroutine task scheduling function is set at the return address of each coroutine's stack space. When a coroutine context switch occurs, control is transferred to the coroutine task scheduling function via the return address, which then controls the scheduling and execution of all coroutine tasks in the coroutine pool on this managed core.

[0144] As a further optional implementation, the step of controlling the host thread to acquire the managed core specifically includes:

[0145] The required number of logical cores is determined based on the service requirements of the application.

[0146] Request managed cores based on the number of logical cores.

[0147] Specifically, the coroutine application notifies the logical core scheduling module of the required number of logical cores, and then each host thread of the coroutine application also requests a managed core from the logical core scheduling module. Once the host thread successfully obtains a managed core, it enters the "running state".

[0148] As a further optional implementation, the step of executing the coroutine task within the host thread through the task scheduling function specifically includes:

[0149] Traverse the coroutine pool to obtain the target coroutine in the coroutine pool;

[0150] Switch the context of the target coroutine;

[0151] The coroutine task is executed in the stack space of the target coroutine.

[0152] Specifically, the task scheduling function execution process includes the following steps:

[0153] Traverse the coroutine pool and use a round-robin approach to find coroutines that are in an "occupied state" and use them as target coroutines.

[0154] A switch is performed from the current coroutine context to the target coroutine context. Then, the coroutine task scheduler finds the address and parameters of the target coroutine's task processing function and executes the task processing function in the target coroutine's stack space.

[0155] Once a coroutine task has finished executing, the coroutine task scheduling function updates the target coroutine's status to "idle," and the coroutine can then be repurposed for coroutine task allocation.

[0156] When there are no coroutine tasks to execute, meaning all coroutines in the coroutine pool are in the "idle" state, the coroutine task scheduler performs a context switch on the current coroutine's stack space, returning to the host thread's stack space, and control is returned to the host thread. This process continues until the host thread finishes running.

[0157] Reference Figure 3 The present invention provides a coroutine pool scheduling and management system, comprising:

[0158] The first module 301 is used to create corresponding coroutine tasks based on the service requirements of the application.

[0159] The second module 302 is used to establish and initialize the coroutine pool of the host thread;

[0160] The third module 303 is used to control the host thread to acquire the managed core and start the host thread;

[0161] The fourth module 304 is used to execute the coroutine task within the host thread through the task scheduling function.

[0162] The content of the above method embodiments is applicable to this system embodiment. The specific functions implemented in this system embodiment are the same as those in the above method embodiments, and the beneficial effects achieved are also the same as those achieved in the above method embodiments.

[0163] Reference Figure 4 This invention provides a coroutine pool scheduling and management device, comprising:

[0164] At least one processor 401;

[0165] At least one memory 402 is used to store at least one program;

[0166] When the at least one program is executed by the at least one processor 401, the at least one processor 401 performs... Figure 1 The method for scheduling and managing the coroutine pool is shown.

[0167] The content of the above method embodiments is applicable to the device embodiments. The specific functions implemented by the device embodiments are the same as those of the above method embodiments, and the beneficial effects achieved are also the same as those achieved by the above method embodiments.

[0168] This invention also provides a storage medium storing processor-executable instructions, which, when executed by a processor, are used to implement... Figure 1 The method for scheduling and managing the coroutine pool is shown.

[0169] It is understood that, compared with the prior art, the embodiments of the present invention also have the following advantages:

[0170] 1) This scheduling management method can distinguish the needs of different data processing tasks and implement more targeted and finer-grained coroutine scheduling and execution control.

[0171] 2) This scheduling management method can identify the host thread and implement scheduling control that is different from other kernel threads, without affecting the thread scheduling mechanism of the operating system itself.

[0172] 3) This scheduling management method effectively integrates the operating system's own thread scheduling mechanism, enabling globally unified resource allocation and management of multiple coroutine pools for multi-core processor architectures. This achieves the goal of dynamically allocating processor core resources, significantly improving the application efficiency and performance of coroutine pools on multi-core processor architectures, allowing the overall system performance to scale freely according to changes in data processing task requirements.

[0173] The above is a detailed description of the preferred embodiments of the present invention. However, the present invention is not limited to the embodiments described. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of the present invention. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for managing a coroutine pool scheduling, the method comprising: The method comprises the following steps: ​ According to the service requirements of the application program, the corresponding coroutine task is created; The coroutine pool of the host thread is established and initialized; Control the host thread to obtain a managed core and start the host thread; Execute the coroutine task in the host thread through the task scheduling function; The step of creating a corresponding coroutine task according to the service requirements of the application program specifically comprises: According to the service requirements of the application program, the creation type of the coroutine task is obtained; wherein the creation type includes shared coroutine task and exclusive coroutine task; According to the creation type, the corresponding managed core set is obtained; wherein the type of the managed core set includes shared managed core set and exclusive managed core set; According to the managed core set, the coroutine task is created; The step of creating a coroutine task according to the managed core set specifically comprises: Determine the target coroutine pool in the managed core set; Create a coroutine task on the target coroutine pool; When the creation type is determined as the shared coroutine task, the shared managed core set corresponding to the application program is obtained, if the shared managed core set is empty, the creation of the coroutine task fails; if the shared managed core set is not empty, a managed core with the lightest load is selected from the shared managed core set, and the target coroutine pool is determined according to the selected managed core; When the creation type is determined as the exclusive coroutine task, the shared managed core set and the exclusive managed core set corresponding to the application program are obtained, if the exclusive managed core set is not empty, a managed core not assigned with any coroutine task is selected from the exclusive managed core set, and the target coroutine pool is determined according to the selected managed core; if the exclusive managed core set is empty or there is no idle managed core in the exclusive managed core set, a managed core is randomly selected from the shared managed core set and added to the exclusive managed core set, and the target coroutine pool is determined according to the randomly selected managed core.

2. The coroutine pool scheduling management method of claim 1, wherein, After the step of executing the coroutine task in the host thread through the task scheduling function, the following steps are further included: Determine that the host thread running is ended, and recycle the managed core.

3. The coroutine pool scheduling management method of claim 1, wherein, The step of initializing the coroutine pool of the host thread specifically comprises: Initialize the state of each coroutine in the coroutine pool; Set the return address in the stack space of each coroutine to the address of the task scheduling function.

4. The coroutine pool scheduling management method of claim 1, wherein, The step of controlling the host thread to obtain a managed core specifically comprises: According to the service requirements of the application program, the number of logical cores required is determined; According to the number of logical cores, the managed core is applied.

5. The coroutine pool scheduling management method of claim 1, wherein, The step of executing the coroutine task in the host thread through the task scheduling function specifically comprises: Iterate through the coroutine pool to obtain a target coroutine in the coroutine pool; Switch the context environment of the target coroutine; Execute the coroutine task in the stack space of the target coroutine.

6. A coroutine pool scheduling management system, characterized by, It comprises: A first module is configured to create a corresponding coroutine task according to the service requirements of an application program; The second module is configured to establish and initialize a coroutine pool of a host thread. The third module is configured to control the host thread to acquire a managed core and start the host thread. The fourth module is configured to execute a coroutine task in the host thread through a task scheduling function. The first module is specifically configured to: According to a service requirement of the application program, a creation type of the coroutine task is acquired, wherein the creation type includes a shared coroutine task and an exclusive coroutine task. According to the creation type, a corresponding managed core set is acquired, wherein a type of the managed core set includes a shared managed core set and an exclusive managed core set. According to the managed core set, the coroutine task is created. The step of creating the coroutine task according to the managed core set specifically includes: The target coroutine pool is determined according to the managed core set. The coroutine task is created on the target coroutine pool. When the creation type is determined as the shared coroutine task, the shared managed core set corresponding to the application program is acquired, if the shared managed core set is empty, the creation of the coroutine task fails, if the shared managed core set is not empty, a managed core with the lightest load is selected from the shared managed core set, and the target coroutine pool is determined according to the selected managed core. When the creation type is determined as the exclusive coroutine task, the shared managed core set and the exclusive managed core set corresponding to the application program are acquired, if the exclusive managed core set is not empty, a managed core without any assigned coroutine task is selected from the exclusive managed core set, and the target coroutine pool is determined according to the selected managed core, if the exclusive managed core set is empty or there is no idle managed core in the exclusive managed core set, a managed core is randomly selected from the shared managed core set and added to the exclusive managed core set, and the target coroutine pool is determined according to the randomly selected managed core.

7. A coroutine pool scheduling management apparatus, characterized by, The at least one processor is configured to implement the coroutine pool scheduling management method in any one of claims 1-5. The processor executable instruction is configured to implement the coroutine pool scheduling management method in any one of claims 1-5 when executed by the processor. The processor executable instruction is configured to implement the coroutine pool scheduling management method in any one of claims 1-5 when executed by the processor. ​ 8. A computer-readable storage medium having stored therein instructions that are executable by a processor, the instructions comprising: ​

Images