A user-mode thread running control method, device and storage medium for pthread and libc compatible interception

Abstract

This application discloses a user-mode thread execution control method, device, and storage medium for pthread and libc-compatible interception, relating to the field of data processing technology. The method, when the scheduler selects an application thread in a ready-to-schedule state, controls the application thread to switch to an active state to execute business logic; when the application thread initiates a blocking call, it intercepts the blocking call and, if it determines that the blocking call cannot be completed immediately, creates a waiting event object corresponding to the blocking call; it determines the target waiting queue corresponding to the calling object of the blocking call and places the waiting event object into the target waiting queue; it controls the application thread to switch to a sleep waiting state to release the CPU for execution by the scheduling thread; and when the scheduling thread receives a ready event corresponding to the waiting event object by calling the kernel interface, it controls the application thread to switch to a ready-to-schedule state, thus reducing CPU resource consumption.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, device and storage medium for controlling the execution of user-mode threads with pthread and libc-compatible interception. Background Technology

[0002] In current Linux systems, all blocking calls initiated by applications, such as read, write, poll, and epoll_wait, are handled independently by the kernel. When a thread performs a blocking operation, it directly triggers a system call switch from user mode to kernel mode. When events such as I / O, signals, and timers arrive, the kernel performs a thread wake-up operation again, completing the context recovery switch from kernel mode to user mode.

[0003] In high-concurrency scenarios, the aforementioned blocking and waiting mode, which is handled in a decentralized manner by the kernel, will cause frequent switching between user mode and kernel mode, saving and restoring of registers, and refreshing of TLB cache due to a large number of concurrent threads frequently entering and leaving the kernel. These operations will consume a lot of CPU resources, causing CPU resources to be consumed in thread switching and kernel management rather than business logic execution.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a user-mode thread execution control method, device, and storage medium for pthread and libc compatible interception, aiming to solve the technical problem of how to reduce CPU resource consumption in blocking call scenarios.

[0006] To achieve the above objectives, this application proposes a user-mode thread execution control method for pthread and libc-compatible interception. The user-mode thread execution control method for pthread and libc-compatible interception includes:

[0007] When the scheduler selects an application thread that is in the ready-to-schedule state, it controls the application thread to switch to the active state so that the application thread can execute business code.

[0008] When the application thread initiates a blocking call, the blocking call is intercepted, and when it is determined that the blocking call cannot be completed immediately, a waiting event object corresponding to the blocking call is created;

[0009] Determine the target waiting queue corresponding to the calling object of the blocking call, and put the waiting event object into the target waiting queue;

[0010] Control the application thread to switch to a sleep waiting state to release the CPU and hand it over to the scheduling thread for execution;

[0011] The scheduling thread is controlled to call the kernel interface. When the kernel interface receives a ready event corresponding to the waiting event object, the application thread is controlled to switch to the ready-to-schedule state. The ready event is used to indicate that the blocking call can be executed immediately.

[0012] In one embodiment, the calling object includes a file descriptor object, a synchronization object, a timer object, and a signal trigger object, wherein the file descriptor object includes ordinary files and socket files.

[0013] In one embodiment, the step of creating the wait event object corresponding to the blocking call includes:

[0014] Based on the type of the calling object of the blocking call, determine the ready event corresponding to the calling object, and use the ready event as the waiting target;

[0015] The application thread to which the blocking call belongs is designated as a waiting thread;

[0016] The waiting event object is created based on the waiting target and the waiting thread.

[0017] In one embodiment, the step of determining the target waiting queue corresponding to the calling object of the blocking call and placing the waiting event object into the target waiting queue includes:

[0018] When the calling object is a file descriptor object, determine the file descriptor of the calling object, determine the target waiting queue based on the file descriptor, and put the waiting event object into the target waiting queue;

[0019] When the calling object is a synchronization object, a timer object, or a signal trigger object, the target waiting queue is determined according to the type of the calling object, and the waiting event object is placed into the target waiting queue.

[0020] In one embodiment, when the calling object of the blocking call is a regular file, the ready event corresponding to the waiting event object is an I / O request completion event;

[0021] The step of controlling the application thread to switch to the ready-to-schedule state when the kernel interface receives a ready event corresponding to the waiting event object further includes:

[0022] When the kernel interface receives the I / O request completion event, it reads the thread control block address from the I / O request completion event.

[0023] The application thread corresponding to the waiting event object is determined based on the address of the thread control block.

[0024] Control the application thread to switch to the ready-to-schedule state.

[0025] In one embodiment, when the calling object of the blocking call is a socket file, the ready event corresponding to the waiting event object is a file descriptor ready event;

[0026] The step of controlling the application thread to switch to the ready-to-schedule state when the kernel interface receives a ready event corresponding to the waiting event object further includes:

[0027] When the kernel interface receives the file descriptor ready event, it reads the file descriptor from the file descriptor ready event;

[0028] Determine the waiting queue corresponding to the file descriptor, and switch the application thread corresponding to the waiting event object in the waiting queue to the ready-to-schedule state.

[0029] In one embodiment, when the calling object of the blocking call is a timer object, the ready event corresponding to the waiting event object is the detection that the current time is greater than or equal to the expiration time of the timer object;

[0030] The step of controlling the application thread to switch to the ready-to-schedule state when the kernel interface receives a ready event corresponding to the waiting event object further includes:

[0031] When the kernel interface detects that the current time is greater than or equal to the expiration time of the timer object, the timer identifier of the timer object is determined;

[0032] The waiting queue of the timer object is determined based on the timer identifier.

[0033] According to the order of the waiting event objects in the waiting queue, the application thread corresponding to the first waiting event object is switched to the ready-to-be-scheduled state.

[0034] In one embodiment, when the calling object of the blocking call is a synchronization object or a signal-triggered object, the ready event corresponding to the waiting event object is the notification signal corresponding to the synchronization object or the signal-triggered object;

[0035] The step of controlling the application thread to switch to the ready-to-schedule state when the kernel interface receives a ready event corresponding to the waiting event object further includes:

[0036] When the kernel interface receives a notification signal corresponding to the synchronization object or the signal triggering object, it switches the application thread corresponding to the first waiting event object from the waiting queue of the synchronization object or the signal triggering object to the ready-to-schedule state according to the order of the waiting event objects.

[0037] Furthermore, to achieve the above objectives, this application also proposes a user-mode thread execution control device for pthread and libc-compatible interception. The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the user-mode thread execution control method for pthread and libc-compatible interception as described above.

[0038] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the user-mode thread execution control method for pthread and libc-compatible interception as described above.

[0039] This application provides a user-mode thread execution control method for pthread and libc-compatible interception. When the scheduler selects an application thread in a ready-to-schedule state, it controls the application thread to switch to an active state so that the application thread can execute business code. When the application thread initiates a blocking call, it intercepts the blocking call and, if it is determined that the blocking call cannot be completed immediately, creates a waiting event object corresponding to the blocking call. It determines the target waiting queue corresponding to the call object of the blocking call and puts the waiting event object into the target waiting queue. It controls the application thread to switch to a sleep waiting state to release the CPU and hand it over to the scheduling thread for execution. It controls the scheduling thread to call the kernel interface. When the kernel interface receives a ready event corresponding to the waiting event object, it controls the application thread to switch to a ready-to-schedule state. The ready event is used to indicate that the blocking call can be executed immediately.

[0040] This method achieves standardized control of blocking calls by intercepting the blocking interfaces of pthread and libc, and migrates various blocking and waiting logics that were traditionally handled independently by the kernel to a user-mode scheduling thread for centralized management. By constructing a unified waiting event object and waiting queue structure, it enables batch harvesting of ready events and unified wake-up distribution through the kernel interface, thus avoiding the overhead of user-mode / kernel-mode switching caused by a large number of application threads frequently entering the kernel for blocking and waking up in high-concurrency scenarios. Attached Figure Description

[0041] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0042] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0043] Figure 1 This is a system architecture diagram provided in Embodiment 1 of the user-mode thread execution control method for pthread and libc-compatible interception in this application;

[0044] Figure 2 Example diagram of unified waiting relationship provided in Embodiment 1 of this application;

[0045] Figure 3 This is a schematic diagram of the method flow provided in Embodiment 2 of the user-mode thread execution control method for pthread and libc compatible interception in this application;

[0046] Figure 4 This is a schematic diagram of the waiting task association provided in Embodiment Six of this application;

[0047] Figure 5 This is a schematic diagram of the method flow provided in Embodiment Six of the User-mode Thread Execution Control Method for Pthread and LibC Compatible Interception in this application;

[0048] Figure 6 This is a schematic diagram of thread state transition provided in Embodiment Six of this application;

[0049] Figure 7 This is a schematic diagram of the dual access mode provided in Embodiment Six of this application;

[0050] Figure 8 This is a schematic diagram of the device structure of the hardware operating environment involved in the user-mode thread execution control method for pthread and libc-compatible interception in the embodiments of this application.

[0051] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0052] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0053] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific embodiments. It should be noted that all actions involving the acquisition of signals, information, or data in this application are performed in accordance with the relevant data protection laws and regulations of the country where the application is located, and with authorization from the owner of the corresponding device.

[0054] In current Linux systems, all blocking calls initiated by applications, such as read, write, poll, and epoll_wait, are handled independently by the kernel. When a thread performs a blocking operation, it directly triggers a system call switch from user mode to kernel mode. When events such as I / O, signals, and timers arrive, the kernel performs a thread wake-up operation again, completing the context recovery switch from kernel mode to user mode.

[0055] In high-concurrency scenarios, the aforementioned blocking and waiting mode, which is handled in a decentralized manner by the kernel, will cause frequent switching between user mode and kernel mode, saving and restoring of registers, and refreshing of TLB cache due to a large number of concurrent threads frequently entering and leaving the kernel. These operations will consume a lot of CPU resources, causing CPU resources to be consumed in thread switching and kernel management rather than business logic execution.

[0056] In view of the above problems, this application proposes a user-mode thread execution control method compatible with pthread and libc. When the scheduler selects an application thread in the ready-to-schedule state, it controls the application thread to switch to the active state so that the application thread can execute business code. When the application thread initiates a blocking call, it intercepts the blocking call and creates a waiting event object corresponding to the blocking call when it is determined that the blocking call cannot be completed immediately. It determines the target waiting queue corresponding to the call object of the blocking call and puts the waiting event object into the target waiting queue. It controls the application thread to switch to the sleep waiting state to release the CPU and hand it over to the scheduling thread for execution. It controls the scheduling thread to call the kernel interface. When the kernel interface receives the ready event corresponding to the waiting event object, it controls the application thread to switch to the ready-to-schedule state. The ready event is used to indicate that the blocking call can be executed immediately.

[0057] This method achieves standardized control of blocking calls by intercepting the blocking interfaces of pthread and libc, and migrates various blocking and waiting logics that were traditionally handled independently by the kernel to a user-mode scheduling thread for centralized management. By constructing a unified waiting event object and waiting queue structure, it enables batch harvesting of ready events and unified wake-up distribution through the kernel interface, thus avoiding the overhead of user-mode / kernel-mode switching caused by a large number of application threads frequently entering the kernel for blocking and waking up in high-concurrency scenarios.

[0058] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device and a user-mode thread execution control system capable of implementing the above functions. The following description uses a user-mode thread execution control system as an example to illustrate the various embodiments.

[0059] First Embodiment

[0060] The first embodiment of this application provides a user-mode thread execution control system for pthread and libc-compatible interception. (Refer to...) Figure 1 , Figure 1 This is a diagram illustrating the architecture of the user-mode thread execution control system provided in this embodiment. Specifically:

[0061] The user-mode thread execution control system includes an application layer, a compatibility interception layer, a thread management module, a file descriptor abstraction module, a wait relationship management module, a scheduling and event loop module, libc (Library of C, C standard library) / libpthread (Library of POSIX Threads, POSIX thread library), and a kernel event source.

[0062] The application layer accesses the compatibility interception layer through the pthread (POSIX Threads, Portable Operating System Interface Threads) interface and the libc interface. When application threads in the application layer initiate blocking calls such as pthread_create(), read(), write(), poll(), epoll_wait(), sleep(), and pthread_cond_wait() through the pthread and libc interfaces, the compatibility interception layer can intercept all pthread and libc blocking calls in the application layer and call the real libc / libpthread to determine whether the blocking call initiated by the application layer can be completed immediately.

[0063] The thread management module maintains the main thread control block, the scheduling thread control block, and the normal application thread control block. The compatibility interception layer connects to both the thread management module and the file descriptor abstraction module, and works with the wait relationship management module to establish a unified wait relationship. The wait relationship management module connects to the scheduling and event loop module to perform unified wake-up dispatch. The scheduling and event loop module connects to the kernel event source.

[0064] The compatibility interception layer takes over the original call entry point of the application layer. The thread management module, file descriptor abstraction module, and wait relationship management module convert the original blocking semantics into a unified wait relationship. The scheduling and event loop module includes a scheduling thread, which is responsible for waiting for the ready event corresponding to the blocking call and resuming the execution of the application thread.

[0065] For example, the overall operation flow of the above-mentioned user-mode thread execution control system includes an initialization phase, a blocking takeover phase, a unified wait construction phase, and a unified wake-up and recovery phase:

[0066] Initialization phase: The main thread control block and the scheduling thread control block are created, and the real libc and real libpthread are loaded. Compatibility interception relationships and the internal event loop environment are established. The main thread registers itself as the first application thread, enters the ready-to-be-scheduled state, and calls upth_create() to create the scheduling thread.

[0067] During the blocking takeover phase: The scheduler selects an application thread, which then switches to an active state to execute business logic. When an application thread initiates a blocking call, the compatibility interception layer first determines whether the blocking call can be completed immediately. If it can be completed immediately, the actual function is called directly to return the result; if it cannot be completed immediately, the waiting relationship management module creates a waiting event object and attaches it to the waiting queue of the calling object of the blocking call, while recording the timeout, retry policy, exception code mapping, and recoverable context. Subsequently, the thread management module saves the relevant registers, stack, and TLS (Thread Local Storage) context of the blocking call, controls the current application thread to switch to a sleep waiting state, and relinquishes CPU (Central Processing Unit) execution rights to the scheduling thread. The scheduling thread starts the event loop and calls kernel interfaces such as epoll_wait() and I / O_uring_peek_cqe() to begin detecting ready events.

[0068] Unified wait construction phase: Constructs the unified wait relationship for the calling objects. These calling objects include file descriptor objects, timer objects, synchronization objects, and signal trigger objects.

[0069] Specifically, a thread control block can be associated with one or more waiting event objects, and multiple waiting event objects can be attached to the wait queue of a file descriptor object. Each waiting event object is associated with both its waiting thread and its waiting target, thus forming a unified wait relationship graph. Each file descriptor (fd) corresponds to a file descriptor abstract object (fd_info), which is used to uniformly represent the runtime state of the file descriptor object and the wait queue that holds the file descriptor objects.

[0070] Timer objects, synchronization objects, and signal-triggered objects maintain their own waiting queues. Taking a timer object as an example, when application thread A and application thread B call timer object a, if the current time has not yet reached the expiration time of timer object a, they respectively create waiting event objects A1 and B1 and add them to the waiting queue of timer object a. The unified waiting relationship for synchronization objects and signal-triggered objects is similar.

[0071] Reference Figure 2 , Figure 2 This diagram illustrates the unified wait relationships for file descriptor objects. In thread control block `pcb_t1`, corresponding to application thread `t1`, there are two blocking calls to the file descriptor object `fd1`. The corresponding wait event objects `fd1_wait_event_t_1` and `fd1_wait_event_t_2` are stored in the wait queue of that file descriptor object. Similarly, in thread control block `pcb_t2`, corresponding to application thread `t2`, there is one blocking call to the file descriptor object `fd1`. The corresponding wait event object `fd1_wait_event_t_3` is also stored in the wait queue of that file descriptor object. Each wait event object is associated with a waiting thread and a waiting target.

[0072] Unified wake-up and recovery phase: If the scheduling thread receives a ready event from the kernel event source through the kernel interface, it will find the corresponding application thread based on the ready event and wake it up, control the application thread to enter the ready-to-schedule state, wait for the scheduler to select it again and continue to execute the business code, and complete the blocking call.

[0073] Second Embodiment

[0074] Based on the user-mode thread execution control system proposed in the first embodiment above, the second embodiment of this application provides a user-mode thread execution control method for pthread and libc-compatible interception, referencing... Figure 3 In this embodiment, the user-mode thread execution control method for pthread and libc-compatible interception includes steps S10-S50:

[0075] In step S10, when the scheduler selects an application thread that is in the ready-to-schedule state, it controls the application thread to switch to the active state so that the application thread can execute business code.

[0076] It should be noted that the scheduler is the control unit responsible for selecting, switching, waking up, enqueuing, and dequeuing application threads in this embodiment. The user-mode thread execution control system stores all application threads in the ready-to-schedule state through a ready queue. The scheduler selects an application thread from the ready queue for execution based on user instructions or preset scheduling logic. An application thread refers to a user-mode thread created using `upth_create()`. It is the execution carrier of business logic, used to execute business code, and initiate pthread and libc blocking calls. The ready-to-schedule state indicates that the application thread has the conditions to run but has not yet been allocated CPU time and is not yet the currently executing thread. The active state indicates that the application thread is executing on the processor.

[0077] Step S20: When the application thread initiates a blocking call, the blocking call is intercepted, and when it is determined that the blocking call cannot be completed immediately, a waiting event object corresponding to the blocking call is created.

[0078] A blocking call refers to a function call initiated by an application thread through the pthread and libc interfaces that causes the thread to pause execution and relinquish the CPU. In this embodiment, the blocking call is taken over by the compatibility interception layer and no longer enters kernel blocking; instead, it switches to user-mode waiting for events.

[0079] The calling object is the target entity that the blocking call waits for, including file descriptor objects, synchronization objects, timer objects, and signal trigger objects. File descriptor objects include regular files (ordinary data files stored on a disk or SSD) and socket files. Synchronization objects include mutexes, condition variables, and semaphores.

[0080] For example, refer to Table 1 below, which provides examples of blocking calls for various types of calling objects.

[0081] Table 1

[0082]

[0083] Furthermore, the step of creating the waiting event object corresponding to the blocking call includes steps S21 to S23:

[0084] Step S21: Based on the type of the calling object of the blocking call, determine the ready event corresponding to the calling object, and use the ready event as the waiting target.

[0085] A ready event is a triggering event that enables a blocking call to meet the execution conditions and can be completed immediately. It is the waiting target of a waiting event object, indicating that the kernel has prepared the data or completed the relevant operation, and the application thread can execute it directly.

[0086] For example, for blocking calls to ordinary files, the aforementioned ready events are the I / O request completion events of the calling object. For blocking calls to socket files, the aforementioned ready events are the file descriptor ready events of the calling object, such as the readable event EPOLLIN, the writable event EPOLLOUT, the exception event EPOLLPRI, the close event EPOLLERR, and the error event EPOLLHUP. For synchronization objects or signal-triggered objects, the aforementioned ready events are the notification signals corresponding to the synchronization object or signal-triggered object. For example, assuming the application thread is blocked in pthread_mutex_lock, its corresponding ready event is the lock release (unlock) notification signal, indicating that the thread holding the lock has released the lock, and the current application thread can immediately acquire the lock; assuming the application thread is blocked in pthread_cond_wait, its corresponding ready event is the condition variable wake-up notification signal. If other threads send condition variable wake-up notification signals such as signal or broadcast, it indicates that the condition has been met, and the current application thread can immediately resume. If the application thread is blocked in sigwait, its corresponding ready event is the arrival notification signal of the target signal specified by the application thread, which indicates that the specified signal has been sent to the current application thread and can be retrieved and returned immediately.

[0087] Step S22: The application thread to which the blocking call belongs is designated as a waiting thread.

[0088] Step S23: Create the waiting event object according to the waiting target and the waiting thread.

[0089] For example, the compatibility interception layer obtains the thread body currently executing the blocking call, identifies this thread as the application thread to which the blocking call belongs, and marks it as a waiting thread. After determining the waiting target and waiting thread, the wait relationship management module allocates memory space for this blocking call, creates a blank wait event object, writes the waiting target into the corresponding field of the wait event object to complete the binding of the waiting condition, and writes the waiting thread or the thread control block address of the waiting thread into the corresponding field of the wait event object to complete the binding of the waiting affiliation. The wait relationship management module can also supplement and populate relevant information such as the waiting type, timeout parameters, trigger conditions, and return result cache according to the blocking call type.

[0090] The above steps, by sequentially determining the waiting target and waiting thread corresponding to the blocking call and completing the creation of the waiting event object, can uniformly transform various blocking calls initiated by the application layer into user-mode waiting entities that can be managed in a standardized manner. This achieves unified abstraction and modeling of different calling objects and different blocking types, ensuring that the blocking behavior of ordinary files, socket files, synchronization objects, timer objects, and signal-triggered objects all adopt a consistent waiting description method. This effectively avoids scattered waiting logic and fragmented wake-up paths, while providing a stable and reliable data carrier and control basis for subsequent thread wake-up. Under the premise of maintaining the original pthread / libc interface semantics unchanged, it supports the entire user-mode thread runtime control system to achieve efficient, unified, and scalable blocking takeover and scheduling control, reducing the overhead of kernel scheduling and blocking wake-up in high-concurrency scenarios.

[0091] Step S30: Determine the target waiting queue corresponding to the calling object of the blocking call, and put the waiting event object into the target waiting queue.

[0092] The above step S30 is executed by the waiting relationship management module. Its core is to locate the target waiting queue dedicated to the calling object based on the calling object type of the blocking call, and to attach the created waiting event object to the target waiting queue, thereby establishing a waiting association between the application thread and the calling object, and providing structural support for subsequent application thread wake-up.

[0093] Optionally, when the calling object is a file descriptor object, the file descriptor of the calling object is determined, the target waiting queue is determined based on the file descriptor, and the waiting event object is placed into the target waiting queue.

[0094] For example, if the calling object is a file descriptor object, the wait relationship management module first obtains the file descriptor corresponding to the calling object, then indexes the corresponding file descriptor abstract object based on the file descriptor, and then determines the target wait queue contained in the file descriptor abstract object.

[0095] In this context, the waiting queue corresponding to the file descriptor object corresponds one-to-one with the file descriptor of the file descriptor object, and the waiting event object in each waiting queue corresponds to the blocking call of the same file descriptor object initiated by different application threads.

[0096] Optionally, when the calling object is a synchronization object, a timer object, or a signal-triggered object, the target waiting queue is determined according to the type of the calling object, and the waiting event object is placed in the target waiting queue.

[0097] For example, if the calling object is a synchronization object, a timer object, or a signal-triggered object, the wait relationship management module directly locates and determines the target wait queue corresponding to that type based on the type of the calling object. Each synchronization object, timer object, or signal-triggered object maintains its own wait queue.

[0098] For example, suppose application thread A initiates a call to a timer object 'a' such as `sleep`. The compatibility interception layer compares the current system time controlled by the user-mode thread with the expiration time of timer object 'a'. If the current time has not yet reached the expiration time, the wait relationship management module treats application thread A as a waiting thread, sets the current time reaching the expiration time as the waiting target, creates a wait event object, and adds this wait event object to the wait queue of timer object 'a'. Here, the expiration time of the timer object = the current system time at the time of the call + the timeout time of the timer object. The timeout time is the duration the application thread specifies to sleep or wait when calling the timer object.

[0099] Similarly, assuming application thread A initiates a blocking call to a synchronization object b, such as `mutex_lock`, the compatibility interception layer checks if the mutex counter value is 0. If it is not 0, it means the mutex is already held by another thread and is in a locked state. At this time, the wait management module uses a mutex counter value of 0 as the wait target, designates application thread A as the waiting thread, creates a wait event object, and adds this wait event object to the wait queue of the synchronization object b. The mutex counter is a core state variable within the mutex used to mark whether the lock is held and whether it can be acquired; it is a standard internal field in libpthread. When the thread holding the synchronization object b executes `mutex_unlock()`, it sets the mutex counter to 0 and iterates through the wait queue of the synchronization object b, waking up the waiting thread of the next wait event object in the queue.

[0100] Step S40: Control the application thread to switch to a sleep waiting state to release the CPU and hand it over to the scheduling thread for execution.

[0101] The sleep-wait state indicates that an application thread has relinquished CPU execution rights and been added to the sleep queue. In other words, in the sleep-wait state, the application thread no longer participates in CPU scheduling and can only be woken up when the corresponding ready event arrives. After the waiting event object has been added to the corresponding target waiting queue, the compatibility interception layer controls the application thread that initiated the blocking call to enter the sleep-wait state, causing it to voluntarily relinquish CPU execution rights and be added to the sleep queue. This allows the CPU resources to be uniformly used by the scheduling thread, enabling the scheduling thread to centrally perform ready event detection and thread wake-up tasks.

[0102] For example, the compatibility interception layer sends a thread suspension instruction to the thread management module, which then saves the current application thread's register context and stack pointer, among other runtime information. The thread management module then marks the application thread's state as sleep-waiting and adds it to the sleep queue maintained by the user-mode thread execution control system. After the application thread completes the state transition, it voluntarily releases its CPU execution rights and stops executing the current instruction. Once the CPU execution rights are released, the user-mode thread execution control system allocates CPU resources to the scheduling thread, granting it execution privileges and allowing it to begin running.

[0103] Step S50: Control the scheduling thread to call the kernel interface. When the kernel interface receives the ready event corresponding to the waiting event object, control the application thread to switch to the ready-to-schedule state. The ready event is used to indicate that the blocking call can be executed immediately.

[0104] The scheduling thread invokes event monitoring and acquisition interfaces provided by the operating system kernel, including epoll_wait, I / O_getevents, and I / O_uring_cq_peek, to monitor ready events corresponding to various wait event objects. When the kernel interface captures a ready event, the scheduling thread finds the corresponding application thread based on the wait event object associated with the ready event, switches the application thread from a sleep waiting state to a ready-to-schedule state, enabling the application thread to resume execution and complete the blocking call.

[0105] In this embodiment, when an application thread initiates a blocking call, it intercepts and quickly determines whether the blocking call can be completed immediately. Blocking calls that cannot be completed immediately are uniformly abstracted as waiting event objects, and these objects are attached to the corresponding target waiting queue according to their type. This achieves standardized modeling and unified management of various blocking scenarios, such as file descriptor objects, synchronization objects, timer objects, and signal trigger objects. Subsequently, by switching the blocked application thread to a sleep waiting state to actively release CPU resources, the high scheduling overhead caused by frequent blocking, suspension, and waking of a large number of threads in kernel mode is avoided. Simultaneously, a dedicated scheduling thread centrally calls the kernel interface to monitor various ready events. When a ready event arrives, the corresponding thread is uniformly woken up and switched to a ready-to-schedule state. This decouples the blocking waiting logic from the thread scheduling logic, reduces the frequency of kernel thread switching and context saving, and enables the user-mode thread execution control system to reduce the overhead of user-mode thread execution control system calls and improve resource utilization when handling a large number of concurrent blocking calls.

[0106] Third Embodiment

[0107] Based on the first and second embodiments described above, in the user-mode thread execution control method for pthread and libc compatible interception provided in this embodiment, when the calling object of the blocking call is a regular file, the ready event corresponding to the waiting event object is an I / O request completion event.

[0108] In this embodiment, the I / O request completion event refers to a completion notification event generated by the kernel after an application thread encapsulates an asynchronous I / O request into an asynchronous I / O request through a compatibility interception layer and submits it to the kernel for execution, for asynchronous read / write or other disk I / O operations on ordinary files. This event is used to indicate that the conditions waited for by the application thread blocked on the ordinary file I / O have been met, and the blocking call can be executed immediately and return a result.

[0109] Based on this, step S50 above includes steps S51 to S53:

[0110] Step S51: When the kernel interface receives the I / O request completion event, it reads the thread control block address in the I / O request completion event.

[0111] Step S52: Determine the application thread corresponding to the waiting event object based on the thread control block address.

[0112] Step S53: Control the application thread to switch to the ready-to-be-scheduled state.

[0113] It's important to note that the Thread Control Block (TCB) is a data structure used by the user-mode thread execution control system to uniquely identify a thread. When an application thread initiates a blocking call whose call object is a regular file, the compatibility interception layer encapsulates the file operation corresponding to the blocking call into an asynchronous I / O request. The TCB address of the application thread initiating the blocking call is recorded in the context information of the asynchronous I / O request, and then submitted to the kernel for execution via the io_uring or libaio mechanism. The scheduling thread, by parsing the TCB address in the I / O request completion event, can accurately locate and wake up the application thread suspended by the blocking call, thus achieving precise wake-up of the blocked thread.

[0114] For example, for blocking calls to ordinary files, the scheduling thread obtains the ready event through the kernel's asynchronous I / O interface. For instance, under the I / O_uring mechanism, the request completion event is obtained through I / O_uring_cq_peek(), and in the libaI / O scenario, the request completion event is obtained through I / O_getevents().

[0115] For example, suppose an application thread executes `read(fd1, buf, 1024)`. The application thread initiates a blocking call to `fd1` by calling `read`. At this point, the compatibility interception layer encapsulates this file read operation as an asynchronous I / O request and sends it to the kernel for execution. It also creates a wait event object and places it in the wait queue corresponding to `fd1`. Afterward, the application thread switches to a sleep state, yielding the CPU to the calling thread, which then checks for ready events through the kernel's asynchronous I / O interface. When the kernel receives the file read operation request, it reads the data from the disk, adds the data to the `buf` buffer, and generates an I / O request completion event. When the kernel asynchronous I / O interface receives the I / O request completion event from the kernel, it determines that it has received the ready event corresponding to the aforementioned wait event object. It reads the thread control block address from the I / O request completion event, identifies the corresponding application thread based on the thread control block address, switches the application thread from the sleep waiting state to the ready-to-schedule state, and places it in the ready queue. When the scheduler selects the application thread from the ready queue again, it continues to execute the above read(fd1,buf,1024). Simultaneously, it can identify the corresponding wait event object in the wait queue based on the aforementioned thread control block address and remove the event wait object from the wait queue.

[0116] This embodiment achieves thread location and wake-up based on the thread control block address in the I / O request completion event, providing an efficient and low-overhead thread management mechanism for user-mode thread execution control in ordinary file blocking scenarios. This process pre-carries the thread control block address in the asynchronous I / O request, allowing the scheduling thread to quickly locate the blocked application thread directly through the address information after obtaining the I / O request completion event, without traversing the waiting queue or performing additional matching queries, thus improving thread wake-up efficiency and event response speed. Simultaneously, waking up based on the uniquely identified thread's thread control block address ensures the accuracy of the wake-up target, avoids false wake-ups, and improves the operational stability of the user-mode thread execution control system.

[0117] Fourth embodiment

[0118] Based on the above embodiments, in the user-mode thread execution control method for pthread and libc compatible interception provided in this embodiment, when the calling object of the blocking call is a socket file, the ready event corresponding to the waiting event object is a file descriptor ready event.

[0119] In this embodiment, the file descriptor ready event refers to a kernel notification event generated for a socket file, used to identify that the socket can perform the corresponding I / O operation. It is also the dedicated ready event for socket class blocking calls.

[0120] Based on this, step S50 above includes steps S54 to S55:

[0121] Step S54: When the kernel interface receives the file descriptor ready event, it reads the file descriptor from the file descriptor ready event.

[0122] Step S55: Determine the waiting queue corresponding to the file descriptor, and switch the application thread corresponding to the waiting event object in the waiting queue to the ready-to-be-scheduled state.

[0123] For example, for blocking calls to socket files, the scheduling thread receives a file descriptor ready event with the file descriptor via `epoll_wait()`. Since there's a one-to-one correspondence between file descriptors and wait queues, when the scheduling thread receives a file descriptor via `epoll_wait()`, it means the corresponding socket file is ready and can be used by application threads to perform related operations. At this point, the scheduling thread finds the file descriptor abstract object, iterates through the wait queue within that object, and switches all waiting threads corresponding to waiting event objects from the sleep state to the ready-to-schedule state, adding them to the ready queue. These threads wait for the scheduler to select the application thread from the ready queue next time and execute the call to the socket file. Simultaneously, all event waiting objects are removed from the wait queue.

[0124] Optionally, the blocking calls corresponding to the socket file may include poll calls and epoll calls.

[0125] When an application thread calls the `poll()` function on a socket object, it receives a `struct pollfd` array. Each element contains: `fd` (file descriptor); `events` (events to be monitored); and `revents` (fields for the kernel's return result). The interceptor layer then takes over the blocking `poll` call, encapsulating the poll monitoring request as a waiting event object, and the application thread enters a sleep state. When the scheduling thread detects a ready event, it finds the corresponding `pollfd` structure (the aforementioned `struct pollfd` array) based on the `fd` in the received ready event, and writes the kernel's returned ready event type (e.g., readable, writable, or error) into the `revents` field, completing the poll result backfilling. Once the application thread switches to the ready-to-schedule state and is selected by the scheduler again, it directly reads the `revents` field from the `pollfd` structure.

[0126] When an application thread calls a socket object via epoll(), epoll maintains its own wait queue. The epoll mechanism is widely used in I / O multiplexing mechanisms for network applications. libupthread implements the epoll mechanism based on the following mechanism:

[0127] The blocking calls corresponding to epoll objects include epoll_create(), epoll_wait(), and epoll_ctl().

[0128] The `epoll_create()` function creates an epoll type file descriptor, which is then used by the subsequent `epoll_wait()` function to wait for the file descriptor abstract object associated with that epoll type file descriptor.

[0129] `epoll_ctl()` is used to add or remove file descriptor events from the corresponding file descriptor abstract object of an `epoll` type file descriptor. For example, if an application thread calls `epoll_ctl(fdA, EPOLL_CTL_ADD, fdB, readable event)`, it adds the waiting readable event of `fdB` to `epoll fdA` using `epoll_ctl()`. Then, when the readable event of `fdB` subsequently occurs, the thread calling `epoll_wait(fdA)` needs to be woken up, and the readable event of `fdB` needs to be added to the triggered event array.

[0130] epoll_wait() is used to wait for events associated with an epoll file descriptor (fd). The return value indicates the number of events that have been triggered.

[0131] For example, taking the waiting for a socket fdB readable event as an example: the application thread initiates a blocking call via epoll_ctl(fdA, EPOLL_CTL_ADD, fdB, readable event), and the object of this blocking call is the logical epoll object "epoll fdA". When the fdB readable event is added to epoll fdA, the user-space thread runs the control system to create the waiting event object corresponding to fdB. This waiting event object is added to the internal index structure of the logical epoll object "epoll fdA", such as a red-black tree. In addition, the waiting event object is also added to the wait queue of the file descriptor abstract object of fdB.

[0132] When the application thread calls epoll_wait(), it waits for the event associated with the epoll file descriptor to occur. The user-mode thread running the control system will then create a waiting event object corresponding to the epoll file descriptor, attach the waiting event object to the waiting queue corresponding to the epoll file descriptor, and switch to the next ready thread.

[0133] When the scheduling thread is executed, it obtains the readable event of the socket fdB based on the kernel call interface epoll_wait(), i.e., libc's epoll_wait(). It then finds the file descriptor abstract object corresponding to the fdB, and subsequently locates the wait event object in the wait queue corresponding to the fdB. Using this wait event object, it can retrieve the file descriptor abstract object corresponding to fdA from epoll fdA, and write the readable event of fdB to the ready event array of the file descriptor abstract object corresponding to fdA, completing the epoll result backfilling. Further, it finds the waiting thread that called epoll_wait() through the wait queue in the file descriptor abstract object corresponding to fdA, wakes up the waiting thread, and inserts it into the ready queue. When the scheduler subsequently selects the same waiting thread again in the ready queue, the aforementioned blocking call is executed, directly reading the readable event of fdB from the ready event array.

[0134] In the example above, the file descriptor abstract object corresponding to `epoll fdA` and `fdB` are associated through an internal index structure, that is, `fdB` is added to the red-black tree inside the logical `epoll` object "epoll fdA". The wait event object corresponding to `fdB` is attached to the wait queue of the file descriptor abstract object of `fdB`. After the scheduling thread receives a readable event from `socket fdB`, it triggers the backfilling of epoll results through `fdB`. Note that `epoll fdA` is a file descriptor abstract object maintained at runtime in user space, not a native kernel epoll instance. Its management relationship with `fdB` is established through internal index structures such as red-black trees. When adding a file descriptor via `epoll_ctl`, the corresponding wait event object is not only attached to the index structure of the logical `epoll` object, but also to the wait queue corresponding to the target file descriptor itself, i.e., `fdB`.

[0135] This embodiment implements unified scheduling and wake-up of threads in socket scenarios based on file descriptor ready events, further improving the compatibility and support of user-mode thread execution control methods for network I / O blocking scenarios. By extracting file descriptors from ready events and locating the corresponding wait queues, all application threads waiting for the socket event can be quickly matched, achieving batch and efficient wake-up of blocked threads under the same file descriptor, avoiding the overhead of querying and matching one by one. Utilizing the one-to-one correspondence between file descriptors and wait queues, the wake-up range can be guaranteed to be accurate without redundant traversal. While maintaining the original interface semantics of pthread and libc unchanged, it achieves efficient user-mode takeover of network socket blocking calls, reducing the overhead of frequent kernel-mode scheduling and thread switching.

[0136] Fifth embodiment

[0137] Based on the above embodiments, in the user-mode thread execution control method for pthread and libc compatible interception provided in this embodiment, when the calling object of the blocking call is a timer object, the ready event corresponding to the waiting event object is the detection that the current time is greater than or equal to the expiration time of the timer object.

[0138] Based on this, step S50 above includes steps S56 to S58:

[0139] Step S56: When the kernel interface detects that the current time is greater than or equal to the expiration time of the timer object, the timer identifier of the timer object is determined.

[0140] Step S57: Determine the waiting queue of the timer object based on the timer identifier.

[0141] Step S58: According to the order of the waiting event objects in the waiting queue, switch the application thread corresponding to the first waiting event object to the ready-to-be-scheduled state.

[0142] For example, during execution, the scheduling thread obtains the current system time through the kernel interface and compares it with the expiration time recorded by each timer object. When the current system time is detected to be greater than or equal to the expiration time, it determines that the waiting condition of the timer object has been met and triggers the ready event of the timer object. The scheduling thread obtains the timer identifier of the ready timer object and uses the timer identifier as the key to find the waiting queue maintained by the timer object itself. Next, the scheduling thread traverses the waiting queue, selects the first waiting event object in the queue, removes it from the timer's waiting queue, and simultaneously treats the waiting thread of that event object as an application thread to be woken up, switches the application thread from a sleep waiting state to a ready-to-schedule state, and places it in the ready queue. The next time the scheduler selects this application thread from the ready queue, it executes a call to the timer object.

[0143] Sixth Embodiment

[0144] Based on the above embodiments, in the user-mode thread execution control method for pthread and libc compatible interception provided in this embodiment, when the calling object of the blocking call is a synchronization object or a signal triggering object, the ready event corresponding to the waiting event object is the notification signal corresponding to the synchronization object or the signal triggering object.

[0145] Based on this, step S50 above includes step S59:

[0146] Step S59: When the kernel interface receives a notification signal corresponding to the synchronization object or the signal triggering object, it switches the application thread corresponding to the first waiting event object from the waiting queue corresponding to the synchronization object or the signal triggering object to the ready-to-schedule state according to the order of the waiting event objects.

[0147] For example, the thread wake-up process corresponding to each synchronization object is given below:

[0148] When an application thread initiates a `pthread_mutex_lock` call to a synchronization object mutex, if the mutex counter is 0, execution proceeds directly. If the mutex counter is not 0, a wait event object is created and added to the mutex's wait queue. When the scheduling thread calls the kernel interface to determine that the mutex counter is 0, it considers this a notification signal from the synchronization object mutex. From the mutex's wait queue, it identifies the first waiting thread for a wait event object according to the order of the waiting event objects, moves that thread to the ready queue to wake it up, and switches it from a sleep waiting state to a ready-to-schedule state.

[0149] When an application thread initiates a `pthread_cond_wait` call to the synchronization object `cond`, a wait event object is created and added to the wait queue of that `cond`. When the scheduling thread receives a call to `pthread_cond_signal / broadcast` from another thread via the kernel interface, it determines that it has received a notification signal from the synchronization object `cond`. From the wait queue of that `cond`, according to the order of the wait event objects, the thread waiting for the first wait event object is identified, and this thread is moved to the ready queue to wake it up, controlling its transition from a sleep waiting state to a ready-to-schedule state.

[0150] When an application thread initiates a `sem_wait` call to the synchronization object `sem`, the semaphore `sem` internally maintains a counter. The kernel interface is used to check if this counter is greater than 0. If it is, the counter is decremented by 1, and the semaphore is retrieved directly without blocking. If the counter is equal to 0, a wait event object is created and added to the wait queue of the synchronization object `sem`. When the scheduling thread calls the kernel interface to confirm that the counter is equal to 0, it determines that it has received a notification signal from the synchronization object `sem`. From the wait queue of `sem`, according to the order of the wait event objects, the first waiting thread of the first wait event object is determined, and this waiting thread is moved to the ready queue to wake it up, controlling its transition from a sleep waiting state to a ready-to-schedule state.

[0151] Rwlock (read-write lock) includes rdlock (read lock) and wrlock (write lock). Internally, it maintains two sets of states and two waiting queues: the current number of readers, whether a writer holds the lock, the reader waiting queue, and the writer waiting queue. When an application thread calls rdlock, if no writer holds the lock, it directly acquires the rdlock, and the current number of readers is incremented by 1; if a writer holds the lock, a wait event object is created and added to the reader waiting queue. When the scheduling thread calls the kernel interface to determine that no writer holds the lock, it considers it to have received a notification signal from the synchronization object rdlock. From the reader waiting queue, according to the order of the wait event objects, it determines the waiting thread of the first wait event object, moves the waiting thread to the ready queue to wake it up, and controls it to switch from the sleep waiting state to the ready-to-schedule state. When an application thread calls wrlock, if no writer holds the lock and the current number of readers is 0, it directly acquires the wrlock; if a writer holds the lock or the current number of readers is not 0, a wait event object is created and added to the writer waiting queue. When the scheduling thread calls the kernel interface to determine that no writer holds the lock and the current number of readers is 0, it determines that it has received a notification signal from the synchronization object wrlock. From the writer waiting queue, according to the order of the waiting event objects, it determines the waiting thread of the first waiting event object, moves the waiting thread into the ready queue to wake it up, and controls it to switch from the sleep waiting state to the ready waiting state.

[0152] For example, for the sigwait and sigwaitinfo signal trigger objects, the corresponding notification signal is the specified target signal that the thread is waiting for; for the sigsuspend and pause signal trigger objects, the corresponding notification signal can be any signal.

[0153] For example, to help understand the implementation flow of the user-mode thread execution control method for pthread and libc-compatible interception obtained by combining the above embodiments, please refer to... Figure 4 , Figure 4 A schematic diagram illustrating the thread state transitions of a user-mode thread execution control method for pthread and libc-compatible interception is provided. Specifically:

[0154] After a thread is created, it first enters the ready-to-schedule state. The scheduler selects the target thread from the active queue and switches it to the active state. If the thread encounters a call that can be completed immediately during execution, it remains active and continues to execute. If it encounters a blocking call that cannot be completed immediately, it sets the corresponding logical wait flag according to the type of the calling object, switches the thread to the sleep waiting state, and creates a wait event object which is then attached to the corresponding wait queue.

[0155] When the calling thread receives a ready event, it generates a corresponding wake-up reason based on the trigger source and clears the corresponding logical wait flag. If the trigger source is a notification signal, the thread is removed from the waiting queue of the waiting event object by the notification wake-up path and re-added to the active queue. If the trigger source is a timer expiration, the corresponding waiting event object in the timer is deleted and the thread returns to the ready-to-schedule state. If the trigger source is a file descriptor event, the corresponding waiting event object is deleted from the waiting queue of the file descriptor object, and the thread is restored to the ready-to-schedule state. When the thread finishes execution or calls pthread_exit, it enters the exit-to-be-reclaimed state.

[0156] For example, refer to Figure 5 , Figure 5A simplified flowchart illustrating the user-space thread execution control method for pthread and libc-compatible interception is provided. Specifically, after an application thread initiates a blocking call, it enters the compatibility interception layer, where a decision node determines whether the blocking call can be completed immediately. If the blocking call can be completed immediately, the call result is returned directly; if the blocking call cannot be completed immediately, a wait event object is created and attached to the target wait queue corresponding to the call object, then the process switches to the scheduling thread. The scheduling thread enters the event loop to wait, and upon the arrival of a ready event, performs a unified wake-up dispatch, restores the corresponding application thread, and finally returns the call result. The wait event object can record different information based on the type of the call object. In the file descriptor object waiting scenario, the waiting target can be recorded; specifically, if the blocking call is a poll call, multiple file descriptors and result backfilling indexes can be recorded; if the blocking call is an epoll call, the logical epoll object and its backfilling cache mechanism can be recorded.

[0157] Reference Figure 6 In this invention, ordinary task waiting nodes (i.e., the waiting event objects corresponding to ordinary file calls), poll waiting nodes (i.e., the waiting event objects corresponding to socket file poll calls), and epoll waiting nodes (i.e., the waiting event objects corresponding to socket file epoll calls) can share the same target file descriptor waiting queue. The target file descriptor waiting queue is traversed by a unified wake-up and dispatch logic after the target file descriptor is ready. For ordinary task waiting nodes, ordinary thread resumption is performed, i.e., execution continues according to the original calling logic; for poll waiting nodes, poll result backfilling is performed; for epoll waiting nodes, epoll result backfilling is performed. Multiple waiting type nodes can be attached to the same target file descriptor waiting queue simultaneously, i.e., multiple call types for the same target file descriptor corresponding to the file.

[0158] Reference Figure 7 , Figure 7 This diagram illustrates the dual-access mode of the compatibility interception layer in the user-mode thread execution control system of this application. This embodiment proposes two operating modes for the compatibility interception layer: a compatibility access mode and a native access mode. The compatibility access mode uses dynamic library takeover mechanisms such as LD_PRELOAD to intercept and maintain compatibility with native system calls of existing applications, allowing access and execution without modifying the application source code. The native access mode, on the other hand, uses dedicated interfaces of the lite_* series or equivalent custom interfaces to allow applications to explicitly access and run. Both access modes are ultimately mounted to the same shared runtime core, sharing a unified thread management module, wait relationship management module, and event wake-up and distribution architecture, ensuring consistent scheduling behavior, performance, and functional characteristics under different access methods.

[0159] This user-mode thread execution control system's runtime core supports various I / O event processing backends, including io_uring, Linux asynchronous I / O, direct I / O, and User-mode TCP. These backends can be selectively connected to and adapted to the runtime core based on the actual application scenario and system environment. All of the aforementioned I / O backends are optional implementations; switching or replacing them will not change the overall architecture of this invention, which is centered on compatible interception, unified waiting relationship construction, and unified wake-up distribution, nor will it affect the independence and integrity of thread management, wait queue management, and scheduling distribution logic.

[0160] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the user-mode thread execution control method of this application for pthread and libc compatible interception. Any simple modifications based on this technical concept are within the protection scope of this application.

[0161] This application provides a user-mode thread execution control device for pthread and libc-compatible interception. The user-mode thread execution control device for pthread and libc-compatible interception includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the user-mode thread execution control method for pthread and libc-compatible interception in the above embodiment 1.

[0162] The following is for reference. Figure 8 This document illustrates a schematic diagram of a user-mode thread execution control device suitable for implementing pthread and libc-compatible interception in the embodiments of this application. The user-mode thread execution control device for pthread and libc-compatible interception in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablet computers (PADs), portable multimedia players (PMPs), and in-vehicle terminals (e.g., in-vehicle navigation terminals), as well as fixed terminals such as digital TVs and desktop computers. Figure 8 The user-mode thread execution control device shown for pthread and libc-compatible interception is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0163] like Figure 8As shown, the user-mode thread execution control device for pthread and libc-compatible interception may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in read-only memory (ROM) 1002 or a program loaded from storage device 1003 into random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the user-mode thread execution control device for pthread and libc-compatible interception. The processing device 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows user-mode thread execution control devices with pthread and libc-compatible interception to communicate wirelessly or wiredly with other devices to exchange data. Although user-mode thread execution control devices with various systems with pthread and libc-compatible interception are shown in the figure, it should be understood that it is not required to implement or have all of the systems shown. More or fewer systems can be implemented alternatively.

[0164] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0165] The user-mode thread execution control device for pthread and libc-compatible interception provided in this application, employing the user-mode thread execution control method for pthread and libc-compatible interception in the above embodiments, can solve the technical problem of how to reduce CPU resource consumption in blocking call scenarios. Compared with the prior art, the beneficial effects of the user-mode thread execution control device for pthread and libc-compatible interception provided in this application are the same as the beneficial effects of the user-mode thread execution control method for pthread and libc-compatible interception provided in the above embodiments, and other technical features in the user-mode thread execution control device for pthread and libc-compatible interception are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0166] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0167] The above description is merely a specific embodiment of this application, but the scope of protection of this application 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 application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0168] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the user-mode thread execution control method for pthread and libc-compatible interception in the above embodiments.

[0169] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0170] The aforementioned computer-readable storage medium may be included in a user-mode thread execution control device for pthread and libc-compatible interception; or it may exist independently and not assembled into a user-mode thread execution control device for pthread and libc-compatible interception.

[0171] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a user-mode thread execution control device targeting pthread and libc-compatible interception, enable the user-mode thread execution control device to write computer program code for performing the operations of this application in one or more programming languages ​​or combinations thereof. These programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computer, partially on the user's computer, or as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0172] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0173] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0174] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described user-mode thread execution control method for pthread and libc-compatible interception, thereby solving the technical problem of reducing CPU resource consumption in blocking call scenarios. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the user-mode thread execution control method for pthread and libc-compatible interception provided in the above embodiments, and will not be repeated here.

[0175] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the user-mode thread execution control method described above for pthread and libc-compatible interception.

[0176] The computer program product provided in this application can solve the technical problem of how to reduce CPU resource consumption in blocking call scenarios. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the user-mode thread execution control method for pthread and libc-compatible interception provided in the above embodiments, and will not be repeated here.

[0177] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A user-mode thread execution control method for pthread and libc-compatible interception, characterized in that, The user-mode thread execution control method for pthread and libc-compatible interception includes: When the scheduler selects an application thread that is in the ready-to-schedule state, it controls the application thread to switch to the active state so that the application thread can execute business code. When the application thread initiates a blocking call, the blocking call is intercepted, and when it is determined that the blocking call cannot be completed immediately, a waiting event object corresponding to the blocking call is created; Determine the target waiting queue corresponding to the calling object of the blocking call, and put the waiting event object into the target waiting queue; Control the application thread to switch to a sleep waiting state to release the CPU and hand it over to the scheduling thread for execution; The scheduling thread is controlled to call the kernel interface. When the kernel interface receives a ready event corresponding to the waiting event object, the application thread is controlled to switch to the ready-to-schedule state. The ready event is used to indicate that the blocking call can be executed immediately.

2. The user-mode thread execution control method for pthread and libc-compatible interception as described in claim 1, characterized in that, The calling objects include file descriptor objects, synchronization objects, timer objects, and signal trigger objects. The file descriptor objects include ordinary files and socket files.

3. The user-mode thread execution control method for pthread and libc-compatible interception as described in claim 1, characterized in that, The step of creating the waiting event object corresponding to the blocking call includes: Based on the type of the calling object of the blocking call, determine the ready event corresponding to the calling object, and use the ready event as the waiting target; The application thread to which the blocking call belongs is designated as a waiting thread; The waiting event object is created based on the waiting target and the waiting thread.

4. The user-mode thread execution control method for pthread and libc-compatible interception as described in any one of claims 1 to 3, characterized in that, The step of determining the target waiting queue corresponding to the calling object of the blocking call and placing the waiting event object into the target waiting queue includes: When the calling object is a file descriptor object, determine the file descriptor of the calling object, determine the target waiting queue based on the file descriptor, and put the waiting event object into the target waiting queue; When the calling object is a synchronization object, a timer object, or a signal trigger object, the target waiting queue is determined according to the type of the calling object, and the waiting event object is placed into the target waiting queue.

5. The user-mode thread execution control method for pthread and libc-compatible interception as described in claim 1, characterized in that, When the calling object of the blocking call is a regular file, the ready event corresponding to the waiting event object is the I / O request completion event; The step of controlling the application thread to switch to the ready-to-schedule state when the kernel interface receives a ready event corresponding to the waiting event object further includes: When the kernel interface receives the I / O request completion event, it reads the thread control block address from the I / O request completion event. The application thread corresponding to the waiting event object is determined based on the address of the thread control block. Control the application thread to switch to the ready-to-schedule state.

6. The user-mode thread execution control method for pthread and libc-compatible interception as described in claim 1, characterized in that, When the calling object of the blocking call is a socket file, the ready event corresponding to the waiting event object is the file descriptor ready event; The step of controlling the application thread to switch to the ready-to-schedule state when the kernel interface receives a ready event corresponding to the waiting event object further includes: When the kernel interface receives the file descriptor ready event, it reads the file descriptor from the file descriptor ready event; Determine the waiting queue corresponding to the file descriptor, and switch the application thread corresponding to the waiting event object in the waiting queue to the ready-to-schedule state.

7. The user-mode thread execution control method for pthread and libc-compatible interception as described in claim 1, characterized in that, When the calling object of the blocking call is a timer object, the ready event corresponding to the waiting event object is the detection that the current time is greater than or equal to the expiration time of the timer object; The step of controlling the application thread to switch to the ready-to-schedule state when the kernel interface receives a ready event corresponding to the waiting event object further includes: When the kernel interface detects that the current time is greater than or equal to the expiration time of the timer object, the timer identifier of the timer object is determined; The waiting queue of the timer object is determined based on the timer identifier. According to the order of the waiting event objects in the waiting queue, the application thread corresponding to the first waiting event object is switched to the ready-to-be-scheduled state.

8. The user-mode thread execution control method for pthread and libc-compatible interception as described in claim 1, characterized in that, When the calling object of the blocking call is a synchronization object or a signal-triggered object, the ready event corresponding to the waiting event object is the notification signal corresponding to the synchronization object or the signal-triggered object; The step of controlling the application thread to switch to the ready-to-schedule state when the kernel interface receives a ready event corresponding to the waiting event object further includes: When the kernel interface receives a notification signal corresponding to the synchronization object or the signal triggering object, it switches the application thread corresponding to the first waiting event object from the waiting queue of the synchronization object or the signal triggering object to the ready-to-schedule state according to the order of the waiting event objects.

9. A user-mode thread execution control device for pthread and libc-compatible interception, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the user-mode thread execution control method for pthread and libc-compatible interception as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the user-mode thread execution control method for pthread and libc-compatible interception as described in any one of claims 1 to 8.

Images