Method and apparatus for managing threads

Abstract

A method and apparatus for managing threads are provided. The method includes creating a first thread, the first thread being a kernel mode thread, the first thread having a first thread context; creating a second thread using the first thread, wherein the second thread is a user mode thread, and the second thread inherits the first thread context; controlling the first thread to enter an idle loop state after the second thread is enqueued to a run queue; and selecting and executing the second thread from the run queue using a scheduling thread.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more specifically to a method and apparatus for managing threads. Background Technology

[0002] Compared to kernel-mode threads, user-mode threads have the advantages of customizable scheduling strategies and lower thread switching costs. Therefore, user-mode threads can meet specific user scheduling needs and improve system performance.

[0003] Currently, user-mode threads are mainly implemented using coroutines. However, compared to standard kernel-mode threads, coroutines lose some functionality, leading to poor compatibility between user-mode and kernel-mode threads. Summary of the Invention

[0004] In view of this, the present disclosure aims to provide a method and apparatus for managing threads, which can improve the compatibility of user-mode threads.

[0005] In a first aspect, a method for managing threads is provided, comprising: creating a first thread, wherein the first thread is a kernel-mode thread and has a first thread context; using the first thread to create a second thread, wherein the second thread is a user-mode thread and inherits the first thread context; after storing the second thread in a run queue, controlling the first thread to enter an idle loop state; and using a scheduling thread to select and execute the second thread from the run queue.

[0006] Optionally, as a possible implementation, the method further includes: receiving a first signal through the scheduling thread; responding to the first signal, using the scheduling thread to control the second thread to stop execution; and storing the second thread back into the run queue.

[0007] Alternatively, as one possible implementation, the first signal is triggered by a timer.

[0008] Optionally, as a possible implementation, the method further includes: receiving a second signal through the first thread; marking the second thread as a signal interruption state in response to the second signal; and processing the second signal using a signal processing thread.

[0009] Optionally, as a possible implementation, after marking the second thread as a signal interruption state, the method further includes: determining whether the second thread is in an execution state; if the second thread is in an execution state, then interrupting the execution of the second thread.

[0010] Optionally, as one possible implementation, the first thread context includes the thread-local variables of the first thread.

[0011] In a second aspect, an apparatus for managing threads is provided, comprising: a first creation unit for creating a first thread, wherein the first thread is a kernel-mode thread and has a first thread context; a second creation unit for creating a second thread using the first thread, wherein the second thread is a user-mode thread and inherits the first thread context; a first control unit for controlling the first thread to enter an idle loop state after storing the second thread in a run queue; and an execution unit for selecting and executing the second thread from the run queue using a scheduling thread.

[0012] Optionally, as a possible implementation, the apparatus further includes: a first receiving unit for receiving a first signal through the scheduling thread; a second control unit for controlling the second thread to stop execution using the scheduling thread in response to the first signal; and a storage unit for storing the second thread back into the running queue.

[0013] Alternatively, as one possible implementation, the first signal is triggered by a timer.

[0014] Optionally, as a possible implementation, the apparatus further includes: a second receiving unit for receiving a second signal through the first thread; a marking unit for marking the second thread as a signal interruption state in response to the second signal; and a processing unit for processing the second signal using a signal processing thread.

[0015] Optionally, as a possible implementation, after marking the second thread as a signal interruption state, the device further includes: a determination unit for determining whether the second thread is in an execution state; and an interruption unit for interrupting the execution of the second thread if the second thread is in an execution state.

[0016] Optionally, as one possible implementation, the first thread context includes the thread-local variables of the first thread.

[0017] Thirdly, an apparatus for managing threads is provided, comprising: a memory for storing instructions; and a processor for executing the instructions stored in the memory to perform the method as described in the first aspect or any possible implementation thereof.

[0018] Fourthly, a computer-readable storage medium is provided, having stored thereon instructions for performing the method described in the first aspect or any possible implementation thereof.

[0019] Fifthly, a computer program product is provided, including instructions for performing the method described in the first aspect or any possible implementation thereof.

[0020] Since a thread context typically contains various information about a thread, such as the states of various registers and the thread stack, this embodiment of the disclosure enables the second thread (i.e., the user-mode thread) to inherit the thread context of the first thread (i.e., the kernel-mode thread), thereby allowing the second thread to also possess the various functions of the kernel-mode thread, which can improve the compatibility between user-mode threads and kernel-mode threads. Attached Figure Description

[0021] Figure 1 This is a diagram illustrating the process of a user program executing a system call.

[0022] Figure 2 This is a flowchart illustrating a method for managing threads provided in an embodiment of this disclosure.

[0023] Figure 3 This is a schematic diagram illustrating the relationship between the first thread and the second thread provided in an embodiment of this disclosure.

[0024] Figure 4 This is a schematic diagram of the process of a first thread entering an idle loop state according to an embodiment of this disclosure.

[0025] Figure 5 This is a schematic diagram of the subsequent operation flow of the first thread and the second thread after the second thread finishes running, according to an embodiment of this disclosure.

[0026] Figure 6 This is a schematic diagram of thread preemptive scheduling provided in an embodiment of this disclosure.

[0027] Figure 7 This is a schematic diagram of the structure of a device for managing threads provided in an embodiment of the present disclosure.

[0028] Figure 8 This is a schematic diagram of the structure of a device for managing threads provided in another embodiment of this disclosure. Detailed Implementation

[0029] The technical solutions of the present disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present disclosure, and not all embodiments.

[0030] To facilitate understanding, the basic concepts involved in the embodiments of this disclosure will be explained first.

[0031] operating system

[0032] An operating system (OS) is a computer program that manages computer hardware and software resources. The operating system handles fundamental tasks such as managing and allocating memory, determining the priority of system resource allocation, controlling input and output devices, operating the network, and managing the file system.

[0033] Computer program

[0034] A computer program, also known as software or a program, is a set of instructions that direct a computer or a device with information processing capabilities to perform actions or make decisions. Programs are typically written in a programming language and run on a specific target computer architecture.

[0035] process

[0036] A process is a single execution of a program on a specific set of data in a computer. It is the basic unit for resource allocation and scheduling in a system and forms the foundation of the operating system architecture. In early process-oriented computer architectures, the process was the fundamental execution entity of a program; in contemporary thread-oriented computer architectures, the process is a container for threads. A program is a description of instructions, data, and their organization; a process is the entity within that program.

[0037] Thread

[0038] A thread is the smallest unit of computation that an operating system can schedule. It is contained within a process and is the actual unit of operation within that process. A thread refers to a single, sequential flow of control within a process. Multiple threads can run concurrently within a single process, each executing different tasks in parallel.

[0039] The core of an operating system is the kernel. The kernel is independent of ordinary applications, possesses high privileges, can access protected memory space, and can access all low-level hardware devices. To ensure system security and prevent system crashes due to application errors, the operating system typically prohibits user programs from directly manipulating the kernel. When an application needs to access the kernel (for example, when an application needs to read a file on the disk), it can do so through the interface provided by the kernel. This interface for accessing the kernel is called the system call interface. The system call interface can be an Application Programming Interface (API).

[0040] To prevent applications from accessing the kernel, operating systems typically divide virtual addresses, or virtual address space. For example, the virtual address space can be divided into user space and kernel space. Virtual address space, also known as virtual memory, is a method of memory management used by the operating system. Kernel space is accessible only to kernel programs, while user space is dedicated to applications or user programs. Code in user space is restricted to using only a local memory space; we can consider these programs to execute in user mode. Code in kernel space can access all memory; we can consider these programs to execute in kernel mode.

[0041] If a user-mode program needs to execute a system call, it needs to switch to kernel mode to execute it, such as... Figure 1 As shown. Kernel programs execute in kernel mode, while user programs execute in user mode. When a system call occurs, the user-mode program initiates the system call. Because the system call involves privileged instructions, and the user-mode program lacks sufficient privileges, its execution is interrupted—this is called a trap. After the interrupt occurs, the program currently executing on the processor is interrupted, and the process jumps to the interrupt handler. The kernel program then begins execution, that is, it begins processing the system call. After the kernel finishes processing, it actively triggers a trap, which causes another interrupt and switches back to user mode.

[0042] When an application executes, the operating system can create one or more processes for that application. A process typically represents a unit for resource allocation by the operating system. A process can usually correspond to one or more threads. A thread is the actual execution unit of a process.

[0043] A central processing unit (CPU) resource (such as a CPU core) can only execute one thread at a time. If multiple threads need to execute, the operating system can divide CPU resources into multiple time slices to improve processing efficiency. Within a time slice, CPU resources can be used to execute one of the multiple threads waiting to be executed. Specifically, the operating system can maintain a run queue. This run queue stores threads that are already in a runnable state. The operating system can select a thread from the run queue to execute according to a scheduling policy. After the thread's time slice expires, regardless of whether the thread has finished executing, the operating system will interrupt the thread's execution and select the next thread from the run queue to execute according to the thread scheduling policy. This process is also called thread switching or context switching.

[0044] The thread scheduling mentioned above can be understood as deciding which thread to run first when multiple threads are in a runnable state. Thread scheduling can be determined based on scheduling policies. Different implementations of the run queue correspond to different scheduling policies.

[0045] Because during thread switching, the previous thread may not have finished executing, the current state of the thread needs to be saved so that it can continue execution from its previous interrupted state when it is scheduled again. Saving the current state can be achieved through the thread context.

[0046] A thread context can be used to record the state of a thread before it is interrupted. A thread context can include a thread stack and multiple registers. These registers can include one or more of the following: an instruction pointer register, a stack pointer register, and the values ​​of multiple segment registers. The instruction pointer register indicates the location of the next instruction to be executed by the current thread. The stack pointer register indicates the top position of the stack. One of the segment registers can be a first segment register, which stores the base address of the current thread-local variables. In other words, thread-local variables can be accessed through the first segment register.

[0047] In addition to the information mentioned above, the thread context can also include a signal mask. Each thread has its own signal mask. A signal mask is a bitmap where each bit corresponds to a signal. If a bit in the bitmap is 0, then sending the signal corresponding to that bitmap to a thread will default to terminating the thread's execution. If a bit in the bitmap is 1, it means that the corresponding signal is temporarily "masked" during the execution of the current signal handler, preventing the thread from nested responses to that signal and thus preventing the thread from terminating its execution.

[0048] As can be seen from the above, as long as the thread context is restored, the thread can continue execution from where it was interrupted, and the thread-local variables can also be restored.

[0049] Threads can include kernel-mode threads and user-mode threads. Kernel-mode threads refer to threads that are aware of the kernel. Most mainstream operating systems now support threads directly at the kernel level, and mainstream thread libraries are also wrappers based on kernel-mode threads. In this application, the threads provided by mainstream thread libraries are also referred to as standard threads. User-mode threads refer to threads that are not aware of the kernel. The operating system is unaware of their existence; user-mode threads are created entirely in user space.

[0050] Compared to kernel-mode threads, user-mode threads have two advantages. First, different programs can easily customize their own scheduling strategies. Second, thread switching costs are lower. These two advantages are explained below.

[0051] Kernel-mode thread scheduling is typically implemented by the operating system. For example, it can be achieved using a thread scheduler provided by the operating system. The scheduling policy for kernel-mode threads is usually not modifiable by the user. Therefore, kernel-mode thread scheduling often fails to meet the actual scheduling needs of users.

[0052] User-mode threads can be controlled by the user, who can implement specific scheduling requirements or strategies according to their actual needs. In some embodiments, users can customize the priorities of different threads, or they can perform CPU isolation and control on different thread groups.

[0053] In other embodiments, users can improve performance by controlling scheduling policies. For example, users can optimize scheduling policies to improve CPU utilization. Threads have various dependencies, commonly including producers (e.g., CPU) and consumers (e.g., threads). If producers don't have enough scheduling opportunities, many consumers may be stuck in a waiting state, preventing the system CPU from being fully utilized. Therefore, user-level threads can be used to adjust scheduling policies, thereby improving CPU utilization. As another example, users can also control the execution order of different threads to manage the locality of access to code and data, thereby improving data cache and instruction cache utilization.

[0054] In addition, switching user-mode threads does not involve, for example, Figure 1 The system calls shown can reduce the switching between user mode and kernel mode, thus reducing thread switching overhead.

[0055] Currently, user-mode threads are primarily implemented using coroutines. Coroutines are lightweight threads, and while they possess the advantages of user-mode threads described above, they lose some functionality and suffer from compatibility issues compared to mainstream kernel-mode threads (hereinafter referred to as standard threads). For example, coroutines do not support thread-local variables, cannot implement preemptive scheduling, and do not support signal communication. Especially in cases of very large codebases or uncontrollable source code libraries, the dependence on these features becomes unavoidable, making the coroutine solution unsuitable.

[0056] As mentioned earlier, standard threads can maintain a segment register through which the operating system can access thread-local variables. However, for the sake of lightweight design, current coroutines do not have a segment register for maintaining thread-local variables, resulting in coroutines not supporting thread-local variables and exhibiting poor compatibility with standard threads.

[0057] For preemptive scheduling, coroutines mainly achieve thread switching or scheduling by running pre-written code. Currently, preemptive scheduling is not supported.

[0058] For signal communication, since coroutines are user-mode threads, and thread identification (ID) requires kernel support, coroutines do not have thread IDs. Because they lack thread IDs, coroutines cannot receive signals, and therefore signal communication is impossible.

[0059] In view of this, in order to solve one or more of the above problems, embodiments of this disclosure provide a method for managing threads. Since the context of a kernel-mode thread contains various information about the kernel-mode thread, embodiments of this disclosure enable user-mode threads to inherit the context of kernel-mode threads, thereby allowing user-mode threads to possess the various functions of kernel-mode threads, thus improving the compatibility between user-mode threads and kernel-mode threads.

[0060] Figure 2 This is a flowchart illustrating a method for managing threads according to an embodiment of this disclosure. Figure 2 As shown, the method for managing threads may include steps S210 to S240. The method in this embodiment can be executed by an operating system. The operating system can be any type of operating system, and this disclosure does not limit this. For example, the operating system can be a Linux operating system, a Windows operating system, etc.

[0061] In step S210, the first thread is created. The first thread can be a kernel-mode thread (such as a pthread). A kernel-mode thread can refer to a thread created using APIs provided by a kernel-level thread library.

[0062] The first thread has a first thread context. After the first thread is created, the first thread context can be initialized. The first thread context can be, for example, `jmpctx`. The first thread context can include one or more of the following: multiple registers, a runtime stack. Registers can include one or more of the following: an instruction pointer register, a stack pointer register, and values ​​of multiple segment registers. In some embodiments, the first thread context can include thread-local variables of the first thread. Thread-local variables can be indicated by the values ​​of segment registers.

[0063] In step S120, a second thread is created using the first thread. The second thread is a user-mode thread (such as uthread), and the second thread inherits the context of the first thread.

[0064] The second thread inherits the context of the first thread, which can mean saving the first thread's context into the second thread's context, allowing the second thread to inherit the state of the first thread. For example, the various registers of the first thread can be saved into the second thread's context. By inheriting the first thread's context, the second thread inherits the first thread's runtime environment (most importantly, the instruction locations of the first thread), thereby improving the compatibility of the second thread.

[0065] In this embodiment, one user-mode thread can correspond to one kernel-mode thread, or in other words, there is a one-to-one correspondence between user-mode threads and kernel-mode threads. If multiple user-mode threads need to be created, then multiple kernel-mode threads also need to be created, each corresponding to one of the multiple user-mode threads.

[0066] In step S130, after storing the second thread in the run queue, the first thread is controlled to enter the idle loop state.

[0067] User-mode threads in a runnable state (such as those in the TASK_RUNNING state) can be placed in the run queue. After a second thread becomes runnable, it is placed in the run queue to await scheduling.

[0068] The idle loop state refers to a state where the thread is not invoked by the operating system. When the first thread enters the idle loop state, the operating system considers it to be in a sleep state and does not require execution. Therefore, the operating system will not actively invoke the first thread. By placing the first thread in the idle loop state, the second thread can fully utilize the resources of the first thread without conflicting with it.

[0069] In step S140, the second thread is selected and executed from the run queue using the scheduling thread.

[0070] The scheduling thread is a kernel-mode thread. It can schedule user-mode threads. The scheduling thread can select a user-mode thread from the run queue according to a certain scheduling policy and execute the selected user-mode thread.

[0071] Furthermore, as described above, current user-mode thread schemes cannot implement preemptive scheduling. Preemptive scheduling can be understood as interrupting the currently executing second thread and executing another thread, allowing the other thread to preempt the scheduling of the second thread. Therefore, implementing preemptive thread scheduling mainly involves interrupting the currently executing thread. Considering that the second thread in this embodiment is executed by the scheduling thread, the interruption of the second thread can be achieved by interrupting the scheduling thread. Since the scheduling thread is a kernel-mode thread and has a thread ID, it can receive signals. Based on this, this embodiment can achieve the interruption of the second thread by sending a special signal to the scheduling thread. In addition, since this special signal is sent to the scheduling thread, it will not conflict with signals sent to user-mode threads or kernel-mode threads, thereby reducing signal conflicts.

[0072] In some embodiments, a scheduling thread can receive a first signal; in response to the first signal, the scheduling thread can stop the execution of the second thread. Upon receiving the first signal, the scheduling thread can interrupt the execution of the second thread. Further, the scheduling thread can select the next user-mode thread from the run queue and execute that next user-mode thread. Of course, to ensure that the second thread can continue to be executed, it can also be placed back into the run queue to await the next scheduling.

[0073] This application embodiment can interrupt the execution of the second thread after the execution time of the second thread exceeds a preset threshold. For example, after the execution time of the second thread exceeds the preset threshold, a first signal is sent to the scheduling thread.

[0074] The first signal can be triggered by a timer. This embodiment of the disclosure can maintain a timer, which can trigger the generation of the first signal after the timer expires. This timer can be reset each time a new user-mode thread is switched to, ensuring that the execution duration of each user-mode thread is equal each time. This avoids the problem of one thread occupying processing resources for an extended period, preventing other threads from receiving timely processing.

[0075] The processing of the first signal can be performed by the signal handling thread. Upon receiving the first signal, the signal handling thread can save the register state of the second thread to the second thread's online file and put the second thread back into the run queue to wait for the next scheduling.

[0076] Regarding the problem of user-mode threads being unable to implement signal communication, this disclosure provides a solution. Since each user-mode thread corresponds to a kernel-mode thread, this disclosure allows signal reception to be implemented through the kernel-mode thread. Although the first thread is in an idle loop state, it can still receive signals normally; that is, signals can be sent to the first thread normally. Furthermore, the signal mask for the first thread can be set normally, such as specifying which signals the first thread can respond to and which it cannot.

[0077] Based on this, embodiments of the present disclosure can utilize a first thread to receive a second signal; in response to the second signal, the second thread can be marked as a signal interruption state. Since the scheduling thread will not execute a thread marked as a signal interruption state, the scheduling thread will not execute the second thread after it is marked as a signal interruption state.

[0078] Upon receiving a second signal, a signal handling thread can be used to process it. The second signal can be associated with a user-registered function; processing the second signal may involve executing that function. Before the signal handling thread processes the second signal, it needs to be marked as interrupted. After the second thread is marked as interrupted, the signal handling thread can process the second signal.

[0079] The second signal can be sent to the kernel thread corresponding to any user-mode thread. For example, the second signal can be sent to the kernel thread corresponding to a currently executing user-mode thread. As another example, the second signal can be sent to the kernel thread corresponding to a user-mode thread waiting to be scheduled in the run queue (a user-mode thread that is not currently being executed).

[0080] If the second signal is being executed, although the operating system will mark the second thread as being in a signal interruption state, the second thread will still be in an execution state. To address this, this embodiment of the disclosure can further determine whether the second thread is currently executing after marking it as being in a signal interruption state. If the second thread is currently executing, its execution is interrupted. After interrupting the execution of the second thread, the signal handling thread is then used to process the second signal, thereby ensuring the correctness of the signal function.

[0081] Interrupting the second thread can be achieved using the preemptive scheduling method described above. For example, a first signal can be sent to the scheduling thread to cause it to interrupt the execution of the second thread.

[0082] After the signal handling thread finishes handling the second signal, it can clear the signal interruption status of the second thread, allowing the second thread to continue execution.

[0083] After the second thread finishes running, the first thread can inherit the context of the second thread, such as saving the context information of the second thread into the context of the first thread. In some embodiments, after the second thread finishes running, the scheduling thread can notify the first thread to exit the idle loop state. The scheduling thread can use any inter-thread communication method to notify the first thread; for example, the scheduling thread can notify the first thread through the pthread_cond_signal() signal. After the first thread exits the idle loop state, it can inherit the context of the second thread to complete the thread's cleanup work, such as releasing system resources and process resources. Specifically, it can release the memory occupied by the thread's return value, thread stack, register state, and other information.

[0084] The following is combined Figures 4-6 Specific examples of embodiments of this disclosure are provided below. It should be noted that the following examples are merely to help those skilled in the art understand the embodiments of this application, and are not intended to limit the embodiments of this application to the illustrated protocols or specific scenarios. Those skilled in the art will obviously be able to make various equivalent modifications or variations based on the following examples, and such modifications or variations also fall within the scope of the embodiments of this application.

[0085] Figure 4 This diagram illustrates the process of the first thread entering the idle loop state. The first thread can enter the idle loop state through a special function, which is used to execute actions such as... Figure 4 The process is shown below.

[0086] See Figure 4 In step S410, allocate and initialize the second thread.

[0087] In step S420, the CPU registers are saved to the context of the second thread.

[0088] In step S430, memory is allocated as a stack for the first thread's idle loop.

[0089] In step S440, the first thread jumps to the stack and prepares to enter the idle loop state.

[0090] In step S450, the first thread stores the second thread in the run queue.

[0091] In step S460, the first thread enters the idle loop state.

[0092] After the second thread finishes running, it can return to the scheduling thread using a special function. The scheduling thread notifies the second thread to exit the idle loop state, and the second thread inherits the state of the first thread and continues execution. The following section combines... Figure 5This section describes the subsequent operation process of the first and second threads after the second thread finishes running.

[0093] See Figure 5 In step S510, the second thread saves the state of the register to the second thread context.

[0094] In step S520, the second thread jumps to the scheduling thread.

[0095] In step S530, the scheduling thread can use some inter-thread communication method (such as pthread_cond_signal()) to notify the first thread to exit the idle loop state.

[0096] In step S540, after the first thread exits the idle loop state, it inherits the context of the second thread and resumes execution.

[0097] The following is combined Figure 6 This section introduces the preemptive scheduling process for user-mode threads.

[0098] The timer triggers the generation of the first signal and sends the first signal to the scheduling thread.

[0099] Upon receiving the first signal, the scheduling thread can interrupt the execution of the second thread. Optionally, the state of the registers can be saved to the context of the second thread within the signal handling thread for use in the next scheduling iteration. Furthermore, the second thread can be added back to the run queue to await the next scheduling iteration.

[0100] The above text combined Figures 1 to 6 The present disclosure describes in detail the method embodiments, which are then combined with the following. Figures 7 to 8 The present disclosure provides a detailed description of the apparatus embodiments. It should be understood that the descriptions of the method embodiments correspond to the descriptions of the apparatus embodiments; therefore, any parts not described in detail can be found in the foregoing method embodiments.

[0101] Figure 7 This is a schematic diagram of a thread management device provided in an embodiment of the present disclosure. The device 700 may include a first creation unit 710, a second creation unit 720, a first control unit 730, and an execution unit 740.

[0102] The first creation unit 710 is used to create a first thread, which is a kernel-mode thread and has a first thread context.

[0103] The second creation unit 720 is used to create a second thread using the first thread, wherein the second thread is a user-mode thread and inherits the context of the first thread.

[0104] The first control unit 730 is used to control the first thread to enter an idle loop state after storing the second thread in the run queue.

[0105] Execution unit 740 is used to select and execute the second thread from the run queue using a scheduling thread.

[0106] Optionally, as a possible implementation, the device 700 further includes: a first receiving unit for receiving a first signal through the scheduling thread; a second control unit for controlling the second thread to stop execution using the scheduling thread in response to the first signal; and a storage unit for storing the second thread back into the running queue.

[0107] Alternatively, as one possible implementation, the first signal is triggered by a timer.

[0108] Optionally, as a possible implementation, the apparatus further includes: a second receiving unit for receiving a second signal through the first thread; a marking unit for marking the second thread as a signal interruption state in response to the second signal; and a processing unit for processing the second signal using a signal processing thread.

[0109] Optionally, as a possible implementation, after marking the second thread as a signal interruption state, the device further includes: a determination unit for determining whether the second thread is in an execution state; and an interruption unit for interrupting the execution of the second thread if the second thread is in an execution state.

[0110] Optionally, as one possible implementation, the first thread context includes the thread-local variables of the first thread.

[0111] Figure 8 This is a schematic diagram of a device for managing threads according to another embodiment of this disclosure. The device 800 can be a device with computing capabilities. The device can be an electronic device with an operating system installed. The device 800 can include a memory 810 and a processor 820. The memory 810 can be used to store executable code. The processor 820 can be used to execute the executable code stored in the memory 810 to implement the steps in the various methods described above. In some embodiments, the device 800 may further include a network interface 830, through which the processor 820 exchanges data with external devices.

[0112] It should be understood that in the embodiments of this disclosure, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0113] It should be understood that in the embodiments of this disclosure, "B corresponding to A" means that B is associated with A, and B can be determined based on A. However, it should also be understood that determining B based on A does not mean that B is determined solely based on A; B can also be determined based on A and / or other information.

[0114] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0115] It should be understood that in the various embodiments of this disclosure, the sequence number of each process does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this disclosure.

[0116] In the several embodiments provided in this disclosure, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0117] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0118] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0119] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this disclosure are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can read or a data storage device such as a server or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., digital video discs, DVDs) or semiconductor media (e.g., solid-state disks, SSDs), etc.

[0120] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for managing threads, comprising: creating a first thread, the first thread being a kernel thread, the first thread having a first thread context, the first thread context including thread-local variables of the first thread; creating a second thread by using the first thread, wherein the second thread is a user thread, and the second thread inherits the first thread context; controlling the first thread to enter an idle loop state after the second thread is put into a run queue, the run queue storing threads that have been in a runnable state; selecting and executing the second thread from the run queue by using a scheduling thread, the scheduling thread being a kernel thread, the scheduling thread being configured to implement scheduling of user threads, the scheduling thread being configured to select a user thread from the run queue according to a scheduling policy and execute the selected user thread; wherein the second thread inherits the first thread context comprises saving the first thread context into the second thread so that the second thread inherits a state and / or a running environment of the first thread; wherein the method further comprises: receiving a first signal by the scheduling thread; in response to the first signal, controlling the second thread to stop execution by the scheduling thread; re-pushing the second thread into the run queue. 2.The method of claim 1, wherein the first signal is triggered by a timer. 3.The method of claim 1 or 2, further comprising: receiving a second signal by the first thread; in response to the second signal, marking the second thread as a signal interruption state; processing the second signal by a signal processing thread. 4.The method of claim 3, after the second thread is marked as the signal interruption state, the method further comprises: determining whether the second thread is in an executing state; if the second thread is in the executing state, interrupting execution of the second thread. 5.An apparatus for managing threads, comprising: a first creating unit configured to create a first thread, the first thread being a kernel thread, the first thread having a first thread context, the first thread context including thread-local variables of the first thread; a second creating unit configured to create a second thread by using the first thread, wherein the second thread is a user thread, and the second thread inherits the first thread context; a first controlling unit configured to control the first thread to enter an idle loop state after the second thread is put into a run queue, the run queue storing threads that have been in a runnable state; an executing unit configured to select and execute the second thread from the run queue by using a scheduling thread, the scheduling thread being a kernel thread, the scheduling thread being configured to implement scheduling of user threads, the scheduling thread being configured to select a user thread from the run queue according to a scheduling policy and execute the selected user thread. The second thread inherits the first thread context, including: saving the first thread context into the second thread, so that the second thread inherits the state and / or running environment of the first thread. The apparatus further includes: a first receiving unit configured to receive a first signal by the scheduling thread; a second control unit configured to control the second thread to stop execution by the scheduling thread in response to the first signal; a storage unit configured to store the second thread into a running queue again.

6. The apparatus of claim 5, wherein the first signal is triggered by a timer.

7. The apparatus of claim 5 or 6, further comprising: a second receiving unit configured to receive a second signal by the first thread; a marking unit configured to mark the second thread as a signal interruption state in response to the second signal; a processing unit configured to process the second signal by a signal processing thread.

8. The apparatus of claim 7, after marking the second thread as the signal interruption state, further comprising: a judging unit configured to judge whether the second thread is in an executing state; an interruption unit configured to interrupt the execution of the second thread if the second thread is in the executing state.

9. An apparatus for managing threads, comprising: a memory configured to store instructions; a processor configured to execute the instructions stored in the memory to perform the method of any one of claims 1-4.

Images