Thread scheduling method and apparatus, electronic device, storage medium, program product

Abstract

The present disclosure relates to a thread scheduling method and device, electronic equipment, storage medium and program product. To solve the problem of overall throughput decline caused by unified thread scheduling mode, a thread scheduling method is proposed, which includes the following operations: determining a thread for executing a Go program related task, wherein the Go program related task is a thread task related to the execution of the Go program; obtaining behavior information of the thread hitting the scheduling path based on the scheduling path related to blocking and recovery of the kernel, wherein the behavior information is information related to the running condition of the thread; determining the task type of the Go program related task based on the behavior information, wherein the task type includes a responsive type, and the responsive type is a task type that needs to be scheduled preferentially, and the Go program related task of the responsive type is the Go program related task recovered from blocking; and scheduling the thread based on the task type, wherein in the case where the task type is determined as the responsive type, the thread is preferentially scheduled, thereby improving the overall throughput.

Description

Technical Field

[0001] This disclosure relates to the field of computers, and more particularly to a thread scheduling method, a thread scheduling device, an electronic device, a storage medium, and a program product. Background Technology

[0002] Go is widely used in cloud computing, network services, middleware, and distributed systems. Go programs use Goroutines as the primary concurrent entities, scheduled in user space by the Go runtime. The operating system kernel can only schedule the threads that execute Goroutines. This execution model gives Go programs high concurrency, but it also means the kernel cannot know what type of Go task a thread is performing. In this situation, the kernel performs uniform scheduling on all threads—regardless of the type of Go task—treating them as ordinary threads. However, this uniform thread scheduling method may fail to schedule threads performing critical Go tasks in a timely manner, leading to a decrease in overall throughput. For Go programs, the real factor affecting throughput is often not an insufficient number of threads, but rather the inability of tasks recovering from blocking to quickly acquire CPU resources. For example, typical Go scenarios such as network request processing, remote procedure calls, cache access, database waiting, and event-driven pipelines all involve numerous execution patterns of "short computation - blocking wait - recovery advance." For example, if a task that has recovered from a blockage continues to be scheduled at the same priority as computationally intensive tasks that occupy the CPU for extended periods, it will slow down the response chain, increase request queuing time, and ultimately lead to a decrease in overall throughput. Therefore, a better thread scheduling technique is needed. Summary of the Invention

[0003] This disclosure provides a thread scheduling method, thread scheduling device, electronic device, storage medium, and program product to at least solve the problem of overall throughput reduction caused by the unified thread scheduling method in related technologies.

[0004] According to a first aspect of the present disclosure, a thread scheduling method is provided, the thread scheduling method comprising: determining a thread executing a Go program-related task, wherein the Go program-related task is a thread task related to the execution of a Go program; obtaining behavioral information of the thread hitting the scheduling path based on a kernel scheduling path related to blocking and resumption, wherein the behavioral information is information related to the running status of the thread; determining the task type of the Go program-related task based on the behavioral information, wherein the task type includes reactive, wherein the reactive type is a task type that needs to be scheduled first, and the reactive Go program-related task is a Go program-related task that resumes from blocking; scheduling the thread based on the task type, wherein if the task type is determined to be reactive, the thread is scheduled first.

[0005] Optionally, obtaining the behavior information of the thread that hits the scheduling path based on the kernel's blocking recovery-related scheduling path includes: detecting whether the scheduling path is hit by the thread through observation points, wherein the observation points are deployed on the scheduling path based on extended Berkeley package filters; and in response to detecting that the scheduling path is hit by the thread, obtaining the behavior information of the thread that hit the scheduling path based on the scheduling path.

[0006] Optionally, the scheduling path includes at least one of the following: a blocking system call path; a sleep path and a wake-up path for the wait queue; a scheduler context switching path; and a CPU time slice consumption or statistics path.

[0007] Optionally, the behavioral information includes at least one of the following: information indicating that the thread enters a blocked state; information indicating that the thread resumes from a blocked state; information related to the continuous running time of the thread; and information related to the CPU usage of the thread.

[0008] Optionally, the task type further includes non-responsive type, and the scheduling of the thread based on the task type includes: scheduling the thread based on the priority corresponding to the task type, wherein the higher the priority corresponding to the task type, the higher the priority of the thread executing the Go program-related task of the task type is scheduled, wherein the priority corresponding to the responsive type is higher than the priority corresponding to the non-responsive type; or, scheduling the thread based on the weight corresponding to the task type, wherein the greater the weight corresponding to the task type, the higher the priority of the thread executing the Go program-related task of the task type is scheduled, wherein the weight corresponding to the responsive type is greater than the weight corresponding to the non-responsive type; or, scheduling the thread based on the scheduling wait time corresponding to the task type, wherein the shorter the scheduling wait time corresponding to the task type, the higher the priority of the thread executing the Go program-related task of the task type is scheduled, wherein the scheduling wait time corresponding to the responsive type is shorter than the scheduling wait time corresponding to the non-responsive type.

[0009] Optionally, determining the task type of the Go program-related task based on the behavioral information includes: obtaining prompt information related to the task type of the Go program-related task from the kernel map, wherein the prompt information is written into the kernel map by the Go runtime; and determining the task type of the Go program-related task based on the behavioral information and the prompt information.

[0010] Optionally, the thread scheduling method further includes: after the thread is scheduled, adjusting the task type of the Go program-related tasks executed by the thread based on the continuous running time and / or CPU usage of the thread.

[0011] Optionally, the non-responsive type includes computational and normal types, wherein the computational Go program-related tasks are Go program-related tasks whose continuous runtime exceeds a first predetermined duration or whose cumulative CPU usage exceeds a second predetermined duration, and the normal Go program-related tasks do not belong to the reactive or computational Go program-related tasks, wherein scheduling the thread based on the priority corresponding to the task type includes: adding the thread to a queue with a priority corresponding to the task type based on the task type, and scheduling the threads in the queue according to the priority of the queue, wherein the priority corresponding to the reactive type is higher than the priority corresponding to the normal type, and the priority corresponding to the normal type is higher than the priority corresponding to the computational type; scheduling the thread based on the weight corresponding to the task type includes: according to the task The thread is assigned a weight corresponding to the task type, and the thread is scheduled based on the weight. The weight corresponding to the responsive type is greater than the weight corresponding to the normal type, and the weight corresponding to the normal type is greater than the weight corresponding to the computational type. Scheduling the thread based on the scheduling wait time corresponding to the task type includes: assigning a scheduling wait time corresponding to the task type to the thread, and scheduling the thread based on the scheduling wait time. The scheduling wait time corresponding to the responsive type is shorter than the scheduling wait time corresponding to the normal type, and the scheduling wait time corresponding to the normal type is shorter than the scheduling wait time corresponding to the computational type.

[0012] According to a second aspect of the present disclosure, a thread scheduling apparatus is provided, the thread scheduling apparatus comprising: a thread determination unit configured to determine threads executing Go program-related tasks, wherein the Go program-related tasks are thread tasks related to the execution of the Go program; a behavior information acquisition unit configured to acquire behavior information of the threads hitting the scheduling path based on kernel scheduling paths related to blocking and resumption, wherein the behavior information is information related to the running status of the threads; a task type determination unit configured to determine the task type of the Go program-related tasks based on the behavior information, wherein the task type includes reactive tasks, wherein the reactive tasks are task types that need to be prioritized for scheduling, and the reactive Go program-related tasks are Go program-related tasks that resume from blocking; and a thread scheduling unit configured to schedule the threads based on the task type, wherein if the task type is determined to be reactive, the thread is prioritized for scheduling.

[0013] Optionally, the behavior information acquisition unit is configured to: detect whether the scheduling path is hit by the thread through observation points, wherein the observation points are deployed on the scheduling path based on the extended Berkeley package filter; and in response to detecting that the scheduling path is hit by the thread, acquire the behavior information of the thread that hit the scheduling path based on the scheduling path.

[0014] Optionally, the scheduling path includes at least one of the following: a blocking system call path; a sleep path and a wake-up path for the wait queue; a scheduler context switching path; and a CPU time slice consumption or statistics path.

[0015] Optionally, the behavioral information includes at least one of the following: information indicating that the thread enters a blocked state; information indicating that the thread resumes from a blocked state; information related to the continuous running time of the thread; and information related to the CPU usage of the thread.

[0016] Optionally, the task type further includes a non-responsive type, and the thread scheduling unit is configured to: schedule the threads based on the priority corresponding to the task type, wherein the higher the priority corresponding to the task type, the higher the priority of the thread executing the Go program-related tasks of the task type is scheduled, wherein the priority corresponding to the responsive type is higher than the priority corresponding to the non-responsive type; or, schedule the threads based on the weight corresponding to the task type, wherein the greater the weight corresponding to the task type, the higher the priority of the thread executing the Go program-related tasks of the task type is scheduled, wherein the weight corresponding to the responsive type is greater than the weight corresponding to the non-responsive type; or, schedule the threads based on the scheduling wait time corresponding to the task type, wherein the shorter the scheduling wait time corresponding to the task type, the higher the priority of the thread executing the Go program-related tasks of the task type is scheduled, wherein the scheduling wait time corresponding to the responsive type is shorter than the scheduling wait time corresponding to the non-responsive type.

[0017] Optionally, the task type determination unit is configured to: obtain prompt information related to the type of the task related to the Go program from the kernel map, wherein the prompt information is written into the kernel map by the Go runtime; and determine the task type of the task related to the Go program based on the behavior information and the prompt information.

[0018] Optionally, the thread scheduling device may further include: an adjustment unit configured to adjust the task type of the Go program-related tasks executed by the thread after the thread is scheduled, based on the continuous running time and / or CPU usage of the thread.

[0019] Optionally, the non-responsive type includes computational and normal types, wherein the computational Go program-related tasks are Go program-related tasks with a continuous runtime exceeding a first predetermined duration or a cumulative CPU usage exceeding a second predetermined duration, and the normal Go program-related tasks do not belong to the reactive or computational Go program-related tasks. Optionally, the thread scheduling unit can be configured to: add the thread to a queue with a priority corresponding to the task type based on the task type, and schedule the threads in the queue according to the priority of the queue, wherein the priority corresponding to the reactive type is higher than the priority corresponding to the normal type, and the priority corresponding to the normal type is higher than the priority corresponding to the computational type. Optionally, the thread scheduling unit can be configured to: assign a weight corresponding to the task type to the thread based on the task type, and schedule the thread based on the weight, wherein the weight corresponding to the reactive type is greater than the weight corresponding to the normal type, and the weight corresponding to the normal type is greater than the weight corresponding to the computational type. Optionally, the thread scheduling unit can be configured to: allocate a scheduling wait time corresponding to the task type to the thread according to the task type, and schedule the thread based on the scheduling wait time, wherein the scheduling wait time corresponding to the responsive type is shorter than the scheduling wait time corresponding to the normal type, and the scheduling wait time corresponding to the normal type is shorter than the scheduling wait time corresponding to the computational type.

[0020] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a memory for storing instructions; and a processor, wherein the processor is configured to execute the instructions to implement a thread scheduling method according to an embodiment of the present disclosure.

[0021] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided that, when instructions in the computer-readable storage medium are executed by at least one processor, causes at least one processor to perform a thread scheduling method according to the present disclosure.

[0022] According to a fifth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, implement a thread scheduling method according to the present disclosure.

[0023] The technical solutions provided by the embodiments of this disclosure bring at least the following beneficial effects: According to the thread scheduling method and apparatus, electronic device, storage medium, and program product of this disclosure, after determining the thread executing Go program-related tasks, the behavior information of the thread hitting the scheduling path can be obtained based on the kernel's scheduling path related to blocking and resumption, and the task type of the Go program-related task can be determined based on the behavior information. The thread is scheduled based on the task type. In the case that the task type is determined to be a task type that needs to be scheduled first (responsive), the thread is scheduled first. Since responsive Go program-related tasks are Go program-related tasks that resume from blocking, the above technical solution can enable Go program-related tasks that resume from blocking to obtain CPU resources as soon as possible, thereby improving the overall throughput.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0025] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0026] Figure 1 This is a flowchart illustrating a thread scheduling method according to an exemplary embodiment of the present disclosure.

[0027] Figure 2 This is a schematic diagram illustrating an example of a task classification model according to an exemplary embodiment of the present disclosure.

[0028] Figure 3 This is a flowchart illustrating an example of a thread scheduling method according to an exemplary embodiment of the present disclosure.

[0029] Figure 4 This is a block diagram of a thread scheduling apparatus according to exemplary embodiments of the present disclosure.

[0030] Figure 5 This is an example illustrating the modules included in a thread scheduling apparatus according to an exemplary embodiment of the present disclosure.

[0031] Figure 6 This is based on exemplary embodiments of the present disclosure. Figure 5 The diagram shows the interaction timing between the modules of the thread scheduling device.

[0032] Figure 7 This is a block diagram of an electronic device according to exemplary embodiments of the present disclosure. Detailed Implementation

[0033] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0034] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following examples do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.

[0035] It should be noted that the phrase "at least one of several items" in this disclosure refers to three parallel cases: "any one of the several items", "a combination of any number of the several items", and "all of the several items". For example, "including at least one of A and B" includes the following three parallel cases: (1) including A; (2) including B; (3) including A and B. Another example is "performing at least one of step one and step two", which means the following three parallel cases: (1) performing step one; (2) performing step two; (3) performing both step one and step two.

[0036] As described in the background section, in existing technologies, the kernel is unaware of the type of Go program task a thread is undertaking or executing, and it consistently employs a uniform thread scheduling method, leading to a decrease in overall throughput. Existing technologies typically improve Go program throughput through the following methods: adjusting the GOMAXPROCS parameter to increase parallelism; optimizing the number of Goroutines, pooling models, and I / O logic in user space; adjusting the resources of the entire process through nice, cgroup, or CPU affinity; relying on the Go runtime's default scheduling policy to fairly reuse Goroutines; and indirectly improving throughput by splitting, rate-limiting, or asynchronously modifying business logic. The typical workflow is as follows: business threads enter the Go runtime, the runtime determines which Goroutine is executed, and the kernel is only responsible for scheduling the threads running that runtime. However, in the existing technology, no matter which improvement method is used, the kernel still only perceives threads. Therefore, when the kernel performs scheduling, it still treats all Go program-related tasks as ordinary threads and schedules them uniformly. That is, all Go program-related tasks are scheduled according to the same scheduling priority. Even Go program-related tasks that have recovered from blocking still need to queue up with other tasks to wait for the kernel to schedule them. This leads to a decrease in the overall throughput of Go programs.

[0037] To address this, this disclosure proposes a thread scheduling method. Given a identified thread executing Go program-related tasks, the method obtains behavioral information of the thread hitting the scheduling path based on the kernel's blocking and recovery-related scheduling paths. Based on this behavioral information, the task type of the Go program-related task is determined, and the thread is scheduled accordingly. Specifically, if the task type is determined to be a priority scheduling type (responsive), the thread is scheduled first. Since responsive Go program-related tasks are Go program-related tasks that have recovered from blocking, this method allows Go program-related tasks that have recovered from blocking to obtain CPU resources as quickly as possible, thereby improving overall throughput through differentiated thread scheduling.

[0038] In this disclosure, "Go program" refers to a program obtained by programming in the Go language. The Go runtime is the Go language runtime system, embedded in the executable file of a Go program, and is responsible for scheduling Goroutines, thread management, memory allocation, and system call coordination. A Goroutine is a lightweight user-space concurrent execution unit in a Go program, not directly perceived by the kernel, and is also known as a "coroutine". The execution of any Goroutine must ultimately occur on a real thread in the kernel.

[0039] Hereinafter, with reference to the accompanying drawings, a thread scheduling method, a thread scheduling apparatus, an electronic device, a storage medium, and a program product according to exemplary embodiments of the present disclosure will be described in detail.

[0040] Figure 1 This is a flowchart illustrating a thread scheduling method according to an exemplary embodiment of the present disclosure.

[0041] Reference Figure 1 In step S110, the thread that executes the Go program-related task is determined. According to the embodiment, the Go program-related task is a thread task related to the execution of the Go program. In other words, the Go program-related task is a thread task to be executed for the purpose of executing the Go program. For example, the Go program-related task may be a thread task belonging to the process space of the Go program that carries the Go runtime execution flow or a thread task that has recently executed a critical path of the Go runtime.

[0042] For example, the thread executing a Go program-related task can be determined by identifying whether the current thread is executing such a task. This can be achieved by: obtaining thread-related information based on the Go runtime's scheduling path when the Go program is executed, where the Go runtime's scheduling path is at least one critical function called by the Go runtime during the program's execution, and the thread-related information is information related to the thread that hits the Go runtime's scheduling path, including at least the thread's identification information; obtaining the current thread's identification information based on the kernel's target path, and then identifying whether the current thread is executing a Go program-related task based on both the current thread's identification information and the thread-related information.

[0043] For example, at least one first observation point deployed on the scheduling path based on eBPF (extended Berkeley Packet Filter) can be used to detect whether the scheduling path is hit by a thread. In response to detecting that the scheduling path is hit by a thread, a first eBPF program is run to collect thread-related information and record the thread-related information in the eBPF map. For example, the identification information of the current thread can be obtained by: detecting whether the target path is hit by the current thread using at least one second observation point deployed on the target path in the kernel based on eBPF; in response to detecting that the target path is hit by the current thread, a second eBPF program is run to obtain the identification information of the current thread.

[0044] eBPF is a mechanism for safely executing programmable logic within the kernel. It allows developers to write safe and efficient programs (eBPF programs) and dynamically load them into kernel space for execution, thus extending kernel functionality without modifying the kernel source code. Deploying observation points on scheduling paths using eBPF allows for real-time, online acquisition of thread-related information with lower overhead. Furthermore, deploying observation points on target paths within the kernel using eBPF allows for real-time, online acquisition of the current thread's identification information with lower overhead, facilitating thread identification in a real-time and online manner.

[0045] For example, the following operations can be used to identify whether the current thread is executing a Go program-related task: querying the thread-related information to see if there is an identifier that matches the current thread's identifier; in response to the absence of an identifier that matches the current thread's identifier in the thread-related information, identifying the current thread as not executing a Go program-related task; in response to the presence of an identifier that matches the current thread's identifier in the thread-related information, or in response to the presence of an identifier that matches the current thread's identifier in the thread-related information and the satisfaction of predetermined conditions related to the thread-related information, identifying the current thread as executing a Go program-related task.

[0046] Optionally, if the current thread is a thread executing Go program-related tasks, other threads in the process to which this thread belongs can also be identified as threads executing Go program-related tasks.

[0047] However, the above examples are merely exemplary ways to determine the thread that executes the Go program's related tasks. This disclosure does not limit how the thread that executes the Go program's related tasks can be determined. In addition to the examples above, any other methods may be used to determine the thread that executes the Go program's related tasks.

[0048] In step S120, based on the kernel's scheduling paths related to blocking and recovery, the behavior information of the threads that hit the scheduling paths is obtained.

[0049] According to an exemplary embodiment, the kernel's scheduling paths related to blocking and resuming include at least one of the following: blocking system call paths; sleep and wake-up paths for wait queues; scheduler context switching paths; and CPU time slice consumption or statistics paths.

[0050] The kernel's blocking system call path refers to the scheduling path used by the kernel to handle a potentially blocking system call (such as `read()`, `recvfrom()`, `open()`, etc.) when a user-space process initiates such a call. This path involves the kernel blocking the process when resources are unavailable, waking it up only when conditions are met. In the kernel, the wait queue is the core mechanism for managing processes or threads that voluntarily sleep when resources are not ready and are awakened when conditions are met. The sleep and wake-up paths of the wait queue are the scheduling paths used to implement sleep and wake-up. The scheduler context switching path refers to the scheduling path used by the kernel to switch from one execution unit to another during process or thread scheduling. Blocking and resuming are important scenarios that trigger context switching; therefore, the scheduler context switching path is closely related to blocking and resuming. When a thread resumes from a blocked state, the kernel scheduler must use the context switching mechanism to make it re-participate in scheduling and execute. The CPU time slice consumption or statistics path is mainly used to statistically analyze the CPU time occupied by processes / threads in user mode and kernel mode, and how the scheduler allocates time slices. The consumption or statistical path of CPU time slices is closely related to blocking recovery. For example, time slice consumption occurs during process / thread execution. Blocking will cause the time slice to be released prematurely. After the blocking is resolved, the process / thread will change from the blocked state to the ready state, but will not continue to execute immediately. Instead, it will wait for the scheduler to allocate a new time slice.

[0051] Behavioral information can be information related to the execution status of a thread that hits a scheduling path. For example, execution status can include execution phases (e.g., whether it enters a blocked state, is woken up or resumed from sleep, or re-enters the ready state), runtime, CPU usage, etc. Optionally, behavioral information can be either the behavioral information of a thread hitting a kernel scheduling path related to blocking and resuming each time, or the behavioral information of threads hitting kernel scheduling paths related to blocking and resuming within a predetermined period. In other words, behavioral information can be the behavioral information of a single thread action, or the behavioral information of a thread within a predetermined period.

[0052] According to an exemplary embodiment, the behavioral information may include at least one of the following: information indicating that the thread enters a blocked state; information indicating that the thread resumes from a blocked state; information related to the continuous runtime of the thread; and information related to the CPU usage of the thread. For example, information indicating that the thread enters a blocked state may be information indicating that the thread enters a blocked interface, such as the time and number of times it enters a blocked interface. For example, information indicating that the thread resumes from a blocked state may be information indicating that the thread is awakened or resumes from a sleep state (e.g., time and number of times) and / or information indicating that the thread re-enters a ready state (e.g., time and number of times). For example, information related to the continuous runtime of the thread may be information indicating the continuous runtime of the thread within the current classification period and / or the cumulative runtime of the thread within a predetermined time window. For example, information related to the CPU usage of the thread may be information indicating the duration the thread occupies the CPU.

[0053] According to an exemplary embodiment, whether a scheduling path is hit by a thread can be detected by deploying observation points on the scheduling path based on eBPF. Subsequently, in response to detecting that a scheduling path is hit by a thread, behavioral information of the thread that hit the scheduling path is obtained based on the scheduling path. Deploying observation points on the scheduling path using eBPF can obtain behavioral information in real time and online with lower overhead, thereby facilitating subsequent thread scheduling in real time and online with lower overhead. Optionally, the obtained behavioral information can be stored in an eBPF map.

[0054] Because the behavior information of threads hitting the scheduling path is obtained based on the kernel's scheduling path related to blocking and resumption, this behavior information can reflect whether the thread has exhibited blocking and resumption-related behaviors (e.g., whether blocking and resumption have occurred). In this case, the thread behavior information can be used to classify the Go program-related tasks executed by the thread.

[0055] like Figure 1 As shown, in step S130, the task type of the Go program-related task is determined based on behavioral information. According to an exemplary embodiment, the task type may include responsive type. Responsive type is the task type that needs to be prioritized for scheduling. A responsive Go program-related task is a Go program-related task that has recovered from blocking. For example, a Go program-related task that has recovered from blocking may be a Go program-related task that recently experienced blocking recovery, or a Go program-related task that experienced blocking recovery within the most recent predetermined time window, or a Go program-related task that experienced blocking recovery more than a predetermined number of times within the most recent predetermined time window. For example, if it is determined based on behavioral information that a thread experienced blocking recovery within the most recent T1 time window, then the type of the Go program-related task executed by the thread is determined to be responsive.

[0056] Optionally, the task type may also include non-responsive tasks. Optionally, non-responsive tasks may include computational and normal tasks. Computational Go program-related tasks may be Go program-related tasks whose continuous runtime exceeds a first predetermined duration or whose cumulative CPU usage exceeds a second predetermined duration. Here, the first predetermined duration may be the same as or different from the second predetermined duration. For example, if it is determined based on behavioral information that the thread runs continuously or has accumulated CPU usage exceeding the same predetermined duration, then the task type of the Go program-related task executed by the thread is determined to be computational. Or, if it is determined based on behavioral information that the thread's cumulative runtime exceeds T2 or its continuous runtime exceeds T3, then the task type of the Go program-related task executed by the thread is determined to be computational. Normal Go program-related tasks may be Go program-related tasks that do not belong to either the responsive or computational categories. In the following text, responsive Go program-related tasks may be simply referred to as responsive tasks, computational Go program-related tasks may be simply referred to as computational tasks, and normal Go program-related tasks may be simply referred to as normal tasks.

[0057] Responsive tasks are characterized by recovery from a blocked (or waiting) state, and typically require only a short CPU time to continue processing requests, wake up downstream processes, or complete a phase of processing; therefore, they require priority in response. Computational tasks are characterized by occupying the CPU continuously for a long time within a certain time window, with less frequent recovery from blocking, and are not sensitive to immediate responses, but they occupy more scheduling opportunities. Ordinary tasks are those that are neither clearly responsive nor do they exhibit obvious continuous computational characteristics.

[0058] To reduce implementation complexity, alternatively, the non-responsive type can be left unclassified. In other words, Go program-related tasks are categorized into only two types: reactive and non-reactive tasks. Any Go program-related task that is not reactive is considered a non-reactive task.

[0059] Defined task types can be stored, and the stored state can be periodically cleaned to prevent outdated data from persisting for a long time.

[0060] Optionally, when determining the task type of a Go program-related task, in addition to behavioral information, prompt information from user space can be further combined to determine the task type, thereby further improving the accuracy and speed of task type determination, making subsequent thread scheduling based on task type more accurate and efficient. Optionally, according to an exemplary embodiment, step S130 may include: obtaining prompt information related to the task type of a Go program-related task from the kernel map, wherein the prompt information is written to the kernel map by the Go runtime; and determining the task type of the Go program-related task based on the behavioral information and the prompt information.

[0061] After determining the task type of the Go program-related task to be executed by the thread, in step S140, the thread can be scheduled based on the task type. Specifically, if the task type is determined to be reactive, the thread is scheduled with priority. That is, a thread executing reactive Go program-related tasks is scheduled before other threads executing Go program-related tasks of other task types.

[0062] According to an exemplary embodiment, as described above, the task type may include responsive and non-responsive types. In this case, step S140 may include: scheduling threads based on the priority corresponding to the task type, wherein the higher the priority corresponding to the task type, the more likely the thread executing the Go program-related task of the task type will be scheduled, wherein the priority corresponding to the responsive type is higher than the priority corresponding to the non-responsive type.

[0063] For example, in cases where non-responsive tasks include both computational and normal tasks, scheduling threads based on the priority corresponding to the task type may include: adding threads to queues with priorities corresponding to the task type, and scheduling the threads in the queues according to the queue priorities. According to an exemplary embodiment, the priority corresponding to a responsive task is higher than the priority corresponding to a normal task, and the priority corresponding to a normal task is higher than the priority corresponding to a computational task. For example, the priority corresponding to a task type may include a first priority (high priority) corresponding to a responsive task, a second priority (low priority) corresponding to a computational task, and a third priority (medium priority) corresponding to a normal task, where the first priority is higher than the third priority, and the third priority is higher than the second priority. If the determined task type is responsive, the thread is added to the high-priority queue corresponding to the responsive task (responsive task queue); if the determined task type is computational, the thread is added to the low-priority queue corresponding to the computational task (computational task queue); and if the determined task type is normal, the thread is added to the medium-priority queue corresponding to the normal task (normal task queue). Subsequently, the threads in the queues are scheduled according to the queue priorities. For example, if the reactive task queue is not empty, threads from the reactive queue are prioritized for scheduling. If the reactive task queue is empty but the regular task queue is not empty, threads from the regular task queue are selected for scheduling. If both the reactive and regular task queues are empty, threads from the computational task queue are selected for scheduling. This scheduling method prioritizes CPU resources for Go programs that have recovered from blocking, without completely losing the ability to process regular and computational tasks.

[0064] As mentioned above, task types can include only responsive and non-responsive types. In this case, only two priority queues need to be maintained, one for responsive tasks and one for non-responsive tasks.

[0065] Optionally, in addition to scheduling threads based on priority corresponding to task type as mentioned above, thread scheduling can also be performed by setting weights. According to an exemplary embodiment, step S140 may optionally include: scheduling threads based on weights corresponding to task types, wherein the higher the weight corresponding to the task type, the higher the priority of scheduling threads executing Go program-related tasks of that task type, and the weight corresponding to responsive tasks is greater than the weight corresponding to non-responsive tasks. Through the above method, threads executing responsive Go program-related tasks can also be scheduled with priority. For example, instead of maintaining explicit three or two types of queues, different weights can be assigned to different task types, and the kernel can select threads for scheduling according to the weights. As mentioned above, optionally, task types may include responsive and non-responsive tasks, and non-responsive tasks may include computational and normal tasks. In this case, according to an exemplary embodiment, threads can be assigned weights corresponding to task types, and threads can be scheduled based on these weights. The weight corresponding to responsive tasks can be greater than the weight corresponding to normal tasks, and the weight corresponding to normal tasks can be greater than the weight corresponding to computational tasks, so that responsive tasks can be scheduled with priority.

[0066] Optionally, in addition to the methods of scheduling threads based on priority and weight corresponding to task type as described above, threads can also be scheduled by controlling the scheduling wait time of threads according to task type. Optionally, step S140 may include: scheduling threads based on the scheduling wait time corresponding to the task type, wherein the shorter the scheduling wait time corresponding to the task type, the higher the priority of scheduling threads executing Go program-related tasks of that task type, and the scheduling wait time corresponding to responsive tasks is shorter than the scheduling wait time corresponding to non-responsive tasks. Through the above method, threads executing responsive Go program-related tasks can also be scheduled with priority. As mentioned above, optionally, task types may include responsive and non-responsive tasks, and non-responsive tasks may include computational and normal tasks. In this case, according to the exemplary embodiment, a scheduling wait time corresponding to the task type can be allocated to the thread according to the task type, and the thread can be scheduled based on the scheduling wait time. The scheduling wait time corresponding to responsive tasks may be shorter than the scheduling wait time corresponding to normal tasks, and the scheduling wait time corresponding to normal tasks may be shorter than the scheduling wait time corresponding to computational tasks, so that responsive tasks can be scheduled with priority.

[0067] Optionally, the thread scheduling method further includes: after a thread is scheduled, adjusting the task type of the Go program-related tasks executed by the thread based on the thread's continuous running time and / or CPU usage. For example, the above adjustment can be achieved through a task classification model.

[0068] Figure 2This is a schematic diagram illustrating an example of a task classification model according to an exemplary embodiment of the present disclosure. Figure 2 As shown, task types can include reactive, computational, and normal. For example, if a reactive task continues to occupy the CPU for an extended period after recovery (i.e., after the thread executing the reactive task is scheduled), it is downgraded to a computational task. If the continuous runtime of a reactive task after recovery exceeds a threshold, it is downgraded to a normal task; otherwise, the original task type is maintained. If a normal task experiences a blocking recovery event, it is converted to a reactive task. If the accumulated CPU usage of a computational task exceeds a threshold, it is converted to a normal task. If a computational task waits for too long, it can also be converted to a normal task through periodic reset or re-evaluation. Optionally, if the waiting time of normal and computational tasks is too long, the proportion of reactive tasks continuously selected for scheduling can be appropriately reduced. This method allows for degrading and starvation prevention control, ensuring that tasks that truly need rapid recovery obtain CPU resources as quickly as possible, while identifying tasks that monopolize the CPU for extended periods and limiting their priority, thereby improving throughput without compromising the fairness of thread scheduling.

[0069] Figure 3 This is a flowchart illustrating an example of a thread scheduling method according to exemplary embodiments of the present disclosure. For a clearer understanding of exemplary implementations of the present disclosure, reference is made below. Figure 3 An example of a thread scheduling method is described.

[0070] like Figure 3As shown, in step S301, it can be identified whether the current thread is executing a Go program-related task. If it is determined in step S302 that the current thread is not executing a Go program-related task, then in step S303, it is scheduled according to the normal thread scheduling method. If it is determined in step S302 that the current thread is executing a Go program-related task, then in step S304, based on the kernel's scheduling paths related to blocking and resumption, behavioral information of threads hitting the scheduling path is collected, for example, information related to blocking entry / wake-up / runtime is collected. In step S305, the task type of the Go program-related task executed by the thread is determined according to the collected information and the task type is updated. In step S306, it is determined whether the thread has experienced blocking resumption according to the task type. If blocking resumption has not occurred, then in step S307, it is determined whether the thread has continuously occupied the CPU for more than a first threshold. If blocking resumption has occurred, then in step S308, the Go program-related task executed by the thread is marked as a reactive task, and in step S309, the thread is added to the high-priority queue. If, in step S307, it is determined that the thread's continuous CPU usage exceeds a threshold, then in step S310, the Go program-related task executed by the thread is marked as a computational task, and in step S311, the thread is added to a low-priority queue. If, in step S307, it is determined that the thread's continuous CPU usage does not exceed the threshold, then in step S312, the Go program-related task executed by the thread is marked as a normal task, and in step S313, the thread is added to a medium-priority queue. Subsequently, in step S314, thread scheduling is performed according to the queue priority, prioritizing threads in the high-priority queue. In step S315, the thread begins execution. In step S316, it is determined whether the thread's continuous execution time exceeds a second threshold. If it exceeds the second threshold, then in step S317, the type of the Go program-related task executed by the thread is downgraded to normal or computational, and the task type is updated. If it does not exceed the second threshold, then in step S318, the current task type is maintained.

[0071] According to the exemplary embodiment, the example of the thread scheduling method described above can be implemented using the following eBPF pseudocode: struct go_sched_state { u32 tid; u64 block_ts; u64 wake_ts; u32 run_time; u32 task_type; }; map go_state_map; SEC("kprobe / block_path") int on_block_enter(struct pt_regs ctx) { u32 tid = (u32)bpf_get_current_pid_tgid(); struct go_sched_state st = {}; struct go_sched_state old; if (!is_go_task(tid)) return 0; old = bpf_map_lookup_elem(&go_state_map,&tid); if (old) st = old; st.tid = tid; st.block_ts = bpf_ktime_get_ns(); st.task_type = TASK_TYPE_GO_RESP; bpf_map_update_elem(&go_state_map,&tid,&st, BPF_ANY); return 0; } SEC("kprobe / wakeup_path") int on_task_wakeup(struct pt_regs ctx) { u32 tid = get_wakeup_tid(ctx); struct go_sched_state st; st = bpf_map_lookup_elem(&go_state_map,&tid); if (!st) return 0; st->wake_ts = bpf_ktime_get_ns(); st->task_type = TASK_TYPE_GO_RESP; return 0; } In the pseudocode above, `struct go_sched_state` stores behavioral and task type information in the eBPF map. Here, `u32 tid` is the thread ID, `u64 block_ts` indicates that the thread has entered a blocked state, `u64 wake_ts` indicates that the thread has entered a woken state, `u32 run_time` is the thread's runtime, and `u32 task_type` is the task type. `on_block_enter(tid)` is used to record when the thread enters a blocked state, and `on_task_wakeup(tid)` is used to record when the thread is woken up. However, the pseudocode implementing the thread scheduling method of this disclosure is not limited to the above example. The above pseudocode is only used to help understand the thread scheduling method of this disclosure and is not intended to limit the thread scheduling method of this disclosure in any way.

[0072] The thread scheduling method disclosed herein can be applied to various scenarios, such as network request processing, pipelined processing, and mixed workload scenarios. For example, in a network request processing scenario, after a request Goroutine waits for network or database results, only a small amount of CPU is needed to continue the response. Using the thread scheduling method disclosed herein, such tasks that resume after being blocked can be prioritized for scheduling. For example, in a pipelined processing scenario, multiple Goroutines are connected in series through channels. Once the upstream is ready with data, the downstream should resume operation as soon as possible. Using the thread scheduling method disclosed herein, pipeline stalls can be reduced. For example, in a mixed workload scenario, responsive tasks and computational tasks may coexist within the same process. Using the thread scheduling method disclosed herein, hierarchical scheduling can prevent these two types of tasks from being completely mixed in the same queue.

[0073] The thread scheduling methods according to various embodiments of this disclosure can improve overall throughput and also bring the following beneficial effects: For example, reducing the queuing time of responsive tasks; by collecting behavioral information, judging task types, and adding responsive tasks to a high-priority queue, these tasks can obtain CPU more quickly after recovery. For example, for a large number of "short execution-blocking-recovery" type threads, invalid waiting in the execution chain can be reduced, increasing the number of requests completed per unit time. For example, by downgrading continuously running ordinary tasks to computational tasks and sending them to a low-priority queue, the suppression effect of computational tasks can be reduced, preventing them from occupying the scheduling opportunities of responsive tasks for a long time. For example, through downgrading and anti-starvation control, high-priority queues can be prevented from monopolizing the CPU for a long time, balancing fairness and sustainable operation. For example, using eBPF for information collection and storage does not require rewriting business code or replacing the Go runtime, resulting in lower engineering implementation costs.

[0074] Figure 4 This is a block diagram of a thread scheduling apparatus according to exemplary embodiments of the present disclosure. (Refer to...) Figure 4 The thread scheduling device 400 may include a thread determination unit 410, a behavior information acquisition unit 420, a task type determination unit 430, and a thread scheduling unit 440. The thread determination unit 410 may be configured to determine threads that execute Go program-related tasks. According to an embodiment, Go program-related tasks are thread tasks related to the execution of the Go program. The behavior information acquisition unit 420 may be configured to acquire behavior information of the thread that hits the scheduling path based on kernel scheduling paths related to blocking and resumption. According to an embodiment, the behavior information is information related to the running status of the thread. The task type determination unit 430 may be configured to determine the task type of the Go program-related task based on the behavior information, wherein the task type includes reactive, where the reactive type is a task type that needs to be prioritized for scheduling, and the reactive Go program-related task is a Go program-related task that resumes from blocking. The thread scheduling unit 440 may be configured to schedule the thread based on the task type, wherein if the task type is determined to be reactive, the thread is prioritized for scheduling.

[0075] Optionally, the behavior information acquisition unit 420 can be configured to detect whether the scheduling path is hit by the thread through observation points, wherein the observation points are deployed on the scheduling path based on eBPF; in response to detecting that the scheduling path is hit by the thread, behavior information of the thread that hit the scheduling path is acquired based on the scheduling path.

[0076] Optionally, the scheduling path may include at least one of the following: a blocking system call path; a sleep path and a wake-up path for the wait queue; a scheduler context switching path; or a CPU time slice consumption or statistics path.

[0077] Optionally, the behavioral information may include at least one of the following: information indicating that the thread enters a blocked state; information indicating that the thread resumes from a blocked state; information related to the continuous running time of the thread; and information related to the CPU usage of the thread.

[0078] Optionally, the task type further includes a non-responsive type, and the thread scheduling unit 440 can be configured to: schedule the threads based on the priority corresponding to the task type, wherein the higher the priority corresponding to the task type, the higher the priority of the thread executing the Go program-related task of the task type is scheduled, wherein the priority corresponding to the responsive type is higher than the priority corresponding to the non-responsive type; or, schedule the threads based on the weight corresponding to the task type, wherein the greater the weight corresponding to the task type, the higher the priority of the thread executing the Go program-related task of the task type is scheduled, wherein the weight corresponding to the responsive type is greater than the weight corresponding to the non-responsive type; or, schedule the threads based on the scheduling wait time corresponding to the task type, wherein the shorter the scheduling wait time corresponding to the task type, the higher the priority of the thread executing the Go program-related task of the task type is scheduled, wherein the scheduling wait time corresponding to the responsive type is shorter than the scheduling wait time corresponding to the non-responsive type.

[0079] Optionally, the task type determination unit 430 can be configured to: obtain prompt information related to the task type of the Go program-related task from the kernel map, wherein the prompt information is written into the kernel map by the Go runtime; and determine the task type of the Go program-related task based on the behavior information and the prompt information.

[0080] Optionally, the thread scheduling device 400 may further include an adjustment unit (not shown), which is configured to adjust the task type of the Go program-related tasks executed by the thread after the thread is scheduled, based on the continuous running time and / or CPU usage of the thread.

[0081] Optionally, the non-responsive type includes computational and normal types, wherein the computational Go program-related tasks are Go program-related tasks with a continuous runtime exceeding a first predetermined duration or a cumulative CPU usage exceeding a second predetermined duration, and the normal Go program-related tasks do not belong to the reactive or computational Go program-related tasks. Optionally, in this case, the thread scheduling unit 440 can be configured to: add the thread to a queue with a priority corresponding to the task type based on the task type, and schedule the threads in the queue according to the priority of the queue, wherein the priority corresponding to the reactive type is higher than the priority corresponding to the normal type, and the priority corresponding to the normal type is higher than the priority corresponding to the computational type. Optionally, in this case, the thread scheduling unit 440 can be configured to: assign a weight corresponding to the task type to the thread based on the task type, and schedule the thread based on the weight, wherein the weight corresponding to the reactive type is greater than the weight corresponding to the normal type, and the weight corresponding to the normal type is greater than the weight corresponding to the computational type. Optionally, in this case, the thread scheduling unit 440 may be configured to: allocate a scheduling wait time corresponding to the task type to the thread according to the task type, and schedule the thread based on the scheduling wait time, wherein the scheduling wait time corresponding to the responsive type is shorter than the scheduling wait time corresponding to the normal type, and the scheduling wait time corresponding to the normal type is shorter than the scheduling wait time corresponding to the computation type.

[0082] According to the embodiments of this disclosure, after determining the thread executing Go program-related tasks, the thread scheduling device can obtain the behavior information of the thread hitting the scheduling path based on the kernel's scheduling path related to blocking and resumption. Based on the behavior information, it determines the task type of the Go program-related task and schedules the thread based on the task type. In the case where the task type is determined to be a responsive type that needs to be scheduled first, the thread is scheduled first. Since responsive Go program-related tasks are Go program-related tasks that have resumed from blocking, the above method can enable Go program-related tasks that have resumed from blocking to obtain CPU resources as soon as possible, thereby improving the overall throughput through differentiated thread scheduling.

[0083] The relevant examples of the operations performed by each unit of the thread scheduling device have already been described in the description of the thread scheduling method above, and will not be repeated here.

[0084] Figure 5 This is an example illustrating modules included in a thread scheduling apparatus according to an exemplary embodiment of the present disclosure. Figure 5In the example, the thread scheduling device may include a thread determination module 501, a behavior acquisition module 502, a task type determination module 503, a storage module 504, a scheduling module 505, and a degradation and starvation prevention module 506. Figure 5 As shown, the thread determination module 501 can determine the thread executing Go-related tasks and provide the identification information of the determined thread to the behavior acquisition module 502. The behavior acquisition module 502 can collect the behavior information of the thread based on the thread's identification information and provide the collected behavior information to the task type determination module 503. The task type determination module 503 can determine the task type of the Go-related task executed by the thread based on the behavior information and save the task type to the storage module 504. The scheduling module 505 can schedule the thread based on the task type determined by the task type determination module 503. After the thread is scheduled, the scheduling module 505 can report the continuous running time and / or CPU usage of the thread to the degradation and anti-starvation module 506. The degradation and anti-starvation module 506 can adjust the task type of the Go program-related task executed by the thread based on the continuous running time and / or CPU usage. For example, if the continuous running time of a responsive task exceeds a threshold after recovery from blocking, it is downgraded to a normal task. After the task type is adjusted, the degradation and starvation prevention module 506 can provide the adjusted task type to the scheduling module 505, or the degradation and starvation prevention module 506 can save the adjusted task type in the storage module 504. The scheduling module 505 can schedule threads according to the adjusted task type.

[0085] although Figure 4 and Figure 5 Different unit or module division methods of the thread scheduling device are shown. However, this disclosure does not limit the unit or module division method and different units or modules can be combined, or units or modules can be further split, or other units or modules can be further added.

[0086] Figure 6 This is based on exemplary embodiments of the present disclosure. Figure 5 The diagram shows the interaction timing between the modules of the thread scheduling device. (This will be combined with...) Figure 6 describe Figure 5 Examples of operations performed by each module and the relationships between the modules.

[0087] like Figure 6As shown, the thread determination module 501 can determine the thread executing Go-related tasks. For example, the thread determination module 501 can identify the thread executing Go-related tasks and send the identified thread information (e.g., identification information) to the behavior acquisition module 502. The behavior acquisition module 502 collects the thread's behavior information, such as information related to the thread entering a blocked state, resuming from a blocked state, and the increase in continuous running time, and writes the behavior information to the storage module 504, and provides the behavior information to the task type determination module 503. The task type determination module 503 can determine the task type of the Go-related task executed by the thread based on the behavior information, and update the task type in the storage module 504. For example, the task type determination module 503 can classify the task into responsive, normal, or computational types based on whether a blocking recovery behavior occurs and CPU usage. The task type determination module 503 can specify the priority queue to which the thread should be added based on the task type. The scheduling module 505 can select the thread to be scheduled according to priority, for example, sending the thread to different priority queues according to the task type, and deciding which queue to select the task from next. Furthermore, after a thread is scheduled, the scheduling module 505 can report the thread's continuous running status, such as the continuous running duration, to the degradation and anti-starvation module 506. The degradation and anti-starvation module 506 can update the degradation result based on the continuous running status and store it in the storage module 504. For example, if a thread in the high-priority queue runs continuously for more than a threshold after being scheduled, the thread's task type is updated from reactive to normal. The degradation and anti-starvation module 506 can adjust the queue in which the thread should be located, or it can adjust the proportion of threads selected from the queue for scheduling, based on the updated task type.

[0088] according to Figure 5 and Figure 6 The implementation not only improves overall throughput by scheduling threads based on task type, but also ensures fairness in thread scheduling while improving overall throughput by adjusting task types as appropriate.

[0089] According to embodiments of this disclosure, an electronic device may also be provided. Figure 7 This is a block diagram of an electronic device according to embodiments of the present disclosure, such as... Figure 7 As shown, the electronic device 700 may include a memory 701 for storing instructions and a processor 702. The processor 702 may be configured to execute the instructions to implement the thread scheduling method according to this disclosure.

[0090] As an example, electronic device 700 may be a PC, tablet, personal digital assistant, smartphone, or other device capable of executing the aforementioned set of instructions. Here, electronic device 700 is not necessarily a single electronic device, but may be any collection of devices or circuits capable of executing the aforementioned instructions (or instruction sets) individually or in combination. Electronic device 700 may also be part of an integrated control system or system manager, or may be configured to interconnect with a portable electronic device locally or remotely (e.g., via wireless transmission) through an interface.

[0091] In electronic device 700, processor 702 may include a central processing unit (CPU), a graphics processing unit (GPU), a programmable logic device, a dedicated processor system, a microcontroller, or a microprocessor. By way of example and not limitation, processor 702 may also include analog processors, digital processors, microprocessors, multi-core processors, processor arrays, network processors, etc.

[0092] The processor 702 can execute instructions or code stored in memory, wherein memory 701 can also store data. Instructions and data can also be sent and received via a network through a network interface device, wherein the network interface device can employ any known transmission protocol.

[0093] The memory 701 can be integrated with the processor 702, for example, by placing RAM or flash memory within an integrated circuit microprocessor. Alternatively, the memory 701 can include a separate device, such as an external disk drive, a storage array, or other storage device usable by any database system. The memory 701 and the processor 702 can be operatively coupled, or can communicate with each other, for example, via I / O ports, network connections, etc., enabling the processor 702 to read files stored in the memory 701.

[0094] In addition, the electronic device 700 may also include a video display (such as a liquid crystal display) and a user interaction interface (such as a keyboard, mouse, touch input device, etc.). All components of the electronic device can be interconnected via a bus and / or network.

[0095] According to embodiments of the present disclosure, a computer-readable storage medium may also be provided, wherein when instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the processor to perform a thread scheduling method according to the present disclosure. Examples of computer-readable storage media herein include: read-only memory (ROM), random access programmable read-only memory (PROM), electrically erasable programmable read-only memory (EEPROM), random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, non-volatile memory, CD-ROM, CD-R, CD+R, CD-RW, CD+RW, DVD-ROM, DVD-R, DVD+R, DVD-RW, DVD+RW, DVD-RAM, BD-ROM, BD-R, BD-R LTH, BD-RE, Blu-ray or optical disc storage, hard disk drive (HDD), solid-state drive (SSD), card storage (such as multimedia cards, secure digital (SD) cards, or ultra-fast digital (XD) cards), magnetic tape, floppy disk, magneto-optical data storage device, optical data storage device, hard disk, solid-state drive, and any other device configured to store a computer program and any associated data, data files, and data structures in a non-transitory manner and to provide the computer program and any associated data, data files, and data structures to a processor or computer so that the processor or computer can execute the computer program. The computer program in the aforementioned computer-readable storage medium can run in an environment deployed in computer devices such as clients, hosts, agent devices, servers, etc. Furthermore, in one example, the computer program and any associated data, data files, and data structures are distributed across a networked computer system, such that the computer program and any associated data, data files, and data structures are stored, accessed, and executed in a distributed manner through one or more processors or computers.

[0096] According to an embodiment of this disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, implement a thread scheduling method according to this disclosure.

[0097] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the appended claims.

[0098] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A thread scheduling method, characterized in that, include: Determine the thread that executes Go program-related tasks, wherein the Go program-related tasks are thread tasks related to the execution of the Go program; Based on the kernel's scheduling paths related to blocking and resumption, obtain the behavioral information of the thread that hits the scheduling path, wherein the behavioral information is information related to the thread's running status; Based on the behavioral information, the task type of the Go program-related task is determined, wherein the task type includes responsive type, wherein the responsive type is the task type that needs to be scheduled first, and the responsive type of Go program-related task is the Go program-related task that has recovered from blocking. The thread is scheduled based on the task type, wherein the thread is scheduled first when the task type is determined to be responsive.

2. The thread scheduling method according to claim 1, characterized in that, The process of obtaining the behavior information of the thread that hits the scheduling path based on the kernel's blocking recovery-related scheduling path includes: The scheduling path is detected by observation points, which are deployed on the scheduling path based on extended Berkeley package filters. In response to detecting that the scheduling path is hit by the thread, the behavior information of the thread that hit the scheduling path is obtained based on the scheduling path.

3. The thread scheduling method according to claim 1, characterized in that, The scheduling path includes at least one of the following: Blocking system call paths; The sleep and wake-up paths of the waiting queue; Scheduler context switching path; CPU time slice consumption or statistics path.

4. The thread scheduling method according to claim 1, characterized in that, The behavioral information includes at least one of the following: Information indicating that the thread has entered a blocked state; Information indicating that the thread has resumed from a blocked state; Information related to the continuous execution time of the thread; Information related to the CPU usage of the thread.

5. The thread scheduling method according to claim 1, characterized in that, The task type also includes non-responsive type, and the scheduling of the thread based on the task type includes: The threads are scheduled based on the priority corresponding to the task type, wherein the higher the priority of the task type, the higher the priority of the thread executing the Go program-related tasks of that task type will be scheduled; wherein the priority of the reactive task type is higher than the priority of the non-reactive task type; or... The threads are scheduled based on the weight corresponding to the task type, wherein the higher the weight of the task type, the higher the priority for scheduling the thread executing the Go program-related tasks of that task type; wherein the weight corresponding to the reactive task type is greater than the weight corresponding to the non-reactive task type; or... The threads are scheduled based on the scheduling wait time corresponding to the task type. The shorter the scheduling wait time corresponding to the task type, the higher the priority of scheduling the thread executing the Go program-related tasks of the task type. The scheduling wait time corresponding to the responsive type is shorter than the scheduling wait time corresponding to the non-responsive type.

6. The thread scheduling method according to claim 1, characterized in that, The process of determining the task type of the Go program's related tasks based on the behavioral information includes: Obtain prompt information related to the task type of the Go program from the kernel map, wherein the prompt information is written into the kernel map by the Go runtime; The task type of the Go program's related tasks is determined based on the behavioral information and the prompt information.

7. The thread scheduling method according to claim 5, characterized in that, The thread scheduling method further includes: After the thread is scheduled, the task type of the Go program-related tasks executed by the thread is adjusted according to the thread's continuous running time and / or CPU usage.

8. The thread scheduling method according to claim 5, characterized in that, The non-responsive type includes computational and normal types. The computational type Go program-related tasks are those whose continuous runtime exceeds a first predetermined duration or whose cumulative CPU usage exceeds a second predetermined duration. The normal type Go program-related tasks do not belong to either the reactive or computational types. The method of scheduling the thread based on the priority corresponding to the task type includes: adding the thread to a queue with a priority corresponding to the task type, and scheduling the thread in the queue according to the priority of the queue, wherein the priority corresponding to the responsive type is higher than the priority corresponding to the normal type, and the priority corresponding to the normal type is higher than the priority corresponding to the computational type. The step of scheduling the thread based on the weight corresponding to the task type includes: assigning a weight corresponding to the task type to the thread according to the task type, and scheduling the thread based on the weight, wherein the weight corresponding to the responsive type is greater than the weight corresponding to the normal type, and the weight corresponding to the normal type is greater than the weight corresponding to the computational type; The process of scheduling the thread based on the scheduling wait time corresponding to the task type includes: allocating a scheduling wait time corresponding to the task type to the thread according to the task type, and scheduling the thread based on the scheduling wait time, wherein the scheduling wait time corresponding to the responsive type is shorter than the scheduling wait time corresponding to the normal type, and the scheduling wait time corresponding to the normal type is shorter than the scheduling wait time corresponding to the computational type.

9. A thread scheduling device, characterized in that, include: The thread determination unit is configured to determine the thread that executes Go program-related tasks, wherein the Go program-related tasks are thread tasks related to the execution of the Go program. The behavior information acquisition unit is configured to acquire behavior information of the thread that hits the scheduling path based on the kernel's scheduling path related to blocking and recovery, wherein the behavior information is information related to the running status of the thread; The task type determination unit is configured to determine the task type of the Go program-related task based on the behavior information, wherein the task type includes responsive type, wherein the responsive type is the task type that needs to be scheduled first, and the responsive type Go program-related task is a Go program-related task that recovers from blocking. A thread scheduling unit is configured to schedule the thread based on the task type, wherein the thread is scheduled first when the task type is determined to be the responsive type.

10. An electronic device, characterized in that, include: Memory used to store instructions; A processor, wherein the processor is configured to execute the instructions to implement the thread scheduling method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by at least one processor, the at least one processor causes the at least one processor to perform the thread scheduling method as described in any one of claims 1 to 8.

12. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the thread scheduling method as described in any one of claims 1 to 8.

Images