Data processing method and device, electronic equipment and medium

Abstract

The invention provides a data processing method and device, electronic equipment and a medium, and belongs to the technical field of cloud computing. The method comprises the following steps of: in any time slice allocated to a consumer driver, when the total byte number recorded by a memory counter is reduced to 0 or data in a cache region is read empty, taking out a producer driver from a blocking queue, adding the producer driver into a ready queue, and controlling the consumer driver to be in a waiting state without offering the allocated time slice; after the waiting duration of the consumer driver reaches a preset duration, allocating a time slice to the producer driver in the ready queue, and awakening the consumer driver through the producer driver; and controlling a producer driving program to write data into the cache region, and controlling a consumer driving program to read data from the cache region, thereby providing a data processing method.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of cloud computing, and particularly relates to a data processing method and device, electronic equipment and medium. BACKGROUND

[0002] In a multi-task operating environment, a system (including an operating system or a database system) needs to manage multiple concurrent query requests and transaction processing. To adapt to the multi-task operating requirements, the system can adopt a time-slice scheduling strategy and a Pipeline execution framework (also referred to as an execution pipeline or a query pipeline). The time-slice scheduling strategy is a process scheduling strategy based on time allocation, which is a method used by a scheduler of the system to allocate processor time to concurrent tasks. The Pipeline execution framework refers to a strategy of organizing and executing components or operations of an execution plan in a pipeline form in system query processing. For the system adopting the time-slice scheduling strategy and the Pipeline execution framework, the speed of writing data by a producer driver upstream of a time-slice task is too fast, and the speed of reading data by a consumer driver is too slow, which leads to system memory shortage, overload or crash and the like.

[0003] However, for the system adopting the time-slice scheduling strategy and the Pipeline execution framework, how to perform data processing becomes a problem to be solved at present. SUMMARY

[0004] Embodiments of the present application provide a data processing method, device, electronic equipment and medium for a system adopting a time-slice scheduling strategy and a Pipeline execution framework. The technical solution is as follows:

[0005] In a first aspect, a data processing method is provided, which is applied to a system adopting a time-slice scheduling strategy and a Pipeline execution framework, and the method comprises:

[0006] In any time slice allocated for a consumer driver, when the total number of bytes of data currently stored in the cache area recorded by the memory counter decreases to 0 or the data of the cache area is read empty, the producer driver is taken out of the blocking queue and added to the ready queue, and the consumer driver is controlled to be in a waiting state without giving up the allocated time slice, the blocking queue is used to store the producer driver stopped from writing data in a blocked state due to giving up the allocated time slice, and the ready queue is used to store the producer driver in a ready state waiting for allocation of a time slice;

[0007] After the consumer driver waits for a preset duration, a time slice is allocated to the producer driver in the ready queue to put the producer driver into a running state, and the consumer driver is woken up by the producer driver to put the consumer driver into a running state.

[0008] The producer driver, which is in a running state, is controlled to write data into the buffer, and the consumer driver, which is in a running state, is controlled to read data from the buffer.

[0009] Secondly, a data processing apparatus is provided, the apparatus being applied to a system employing a time-slice scheduling strategy and a pipeline execution framework, the apparatus comprising:

[0010] The first addition module is used to, within any time slice allocated to the consumer driver, when the total number of bytes of data currently stored in the buffer recorded by the memory counter drops to 0 or the data in the buffer is read empty, remove the producer driver from the blocking queue and add it to the ready queue. The blocking queue is used to store producer drivers that have stopped writing data due to giving up their allocated time slices and are in a blocked state. The ready queue is used to store producer drivers or consumer drivers that are in a ready state and waiting to be allocated time slices.

[0011] The first control module is used to control the consumer driver to be in a waiting state and not to yield the allocated time slice.

[0012] The allocation module is used to allocate a time slice to the producer driver in the ready queue after the waiting time of the consumer driver reaches a preset time, so that the producer driver is in the running state.

[0013] A wake-up module is used to wake up the consumer driver through the producer driver so that the consumer driver is in a running state.

[0014] The second control module is used to control the producer driver, which is in the running state, to write data into the cache.

[0015] The third control module is used to control the consumer driver, which is in operation, to read data from the cache.

[0016] Thirdly, an electronic device is provided, including a processor and a memory; the memory stores at least one piece of program code; the at least one piece of program code is called and executed by the processor to implement the data processing method described in the first aspect.

[0017] Fourthly, a computer-readable storage medium is provided, wherein at least one computer program is stored therein, and the at least one computer program, when executed by a processor, is capable of implementing the data processing method described in the first aspect.

[0018] Fifthly, a computer program product is provided, the computer program product comprising a computer program, which, when executed by a processor, is capable of implementing the data processing method described in the first aspect.

[0019] The beneficial effects of the technical solutions provided in this application are:

[0020] For systems employing time-slice scheduling and a pipeline execution framework, both the producer driver and the consumer driver are allocated time slices. Within these time slices, the producer driver's data write operations and the consumer driver's data read operations are executed in parallel. The producer driver writes data to the buffer faster than the consumer driver reads data from the buffer. Since the buffer's storage space is limited, this embodiment uses a memory counter to monitor its capacity. This counter records the total number of bytes of data currently stored in the buffer. When the total number of bytes recorded by the memory counter reaches a threshold, the producer driver is added to a blocking queue, causing it to relinquish its allocated time slice and stop writing data to the buffer, thus preventing further increases in buffer memory. When the total number of bytes recorded by the memory counter drops to 0 or the buffer is empty, requiring further data writing, the producer driver can be removed from the blocking queue and added to the ready queue. The consumer driver is then kept in a waiting state without relinquishing its allocated time slice. After the consumer driver's waiting time reaches a preset duration, a time slice is allocated to the producer driver in the ready queue, putting the producer driver into a running state. The running producer driver then wakes up the waiting consumer driver, controlling the running producer driver to write data to the buffer and the running consumer driver to read data from the buffer, thus achieving data reading and writing in the buffer. Considering that the producer driver writes data to the buffer faster than the consumer driver reads data, and the producer driver's waiting time is longer when there is a lot of data stored in the buffer, controlling the producer driver to yield its time slice prevents it from unnecessarily consuming system resources, improving system performance. Conversely, driver scheduling consumes system resources; when there is less data stored in the buffer, the consumer driver's waiting time is shorter. By controlling the consumer driver to wait in place without yielding its allocated time slice, the consumption of system scheduling resources is reduced, further improving system performance. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0022] Figure 1 This is a schematic diagram of a Pipeline execution framework;

[0023] Figure 2 This is a schematic diagram of a time-slice scheduling process;

[0024] Figure 3 This is an architecture diagram of a system provided in an embodiment of this application;

[0025] Figure 4 This is a flowchart of a data processing method provided in an embodiment of this application;

[0026] Figure 5 This is a timing diagram of a back pressure process provided in an embodiment of this application;

[0027] Figure 6 This application provides a graph showing the trend of cache memory level changing over time within a standard time slice.

[0028] Figure 7 This is a schematic diagram illustrating the calculation process of a first speed at which a generator driver writes data and a second speed at which a consumer driver reads data, provided in an embodiment of this application.

[0029] Figure 8 This is a schematic diagram of a data processing device structure provided in an embodiment of this application;

[0030] Figure 9 A structural block diagram of an electronic device provided in an exemplary embodiment of this application is shown. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0032] It is understood that the terms "each," "multiple," and "any" used in the embodiments of this application, etc., mean that "multiple" includes two or more, "each" refers to each of the corresponding multiples, and "any" refers to any one of the corresponding multiples. For example, multiple words include 10 words, and "each word" refers to each of the 10 words, while "any word" refers to any one of the 10 words.

[0033] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or refuse.

[0034] With the development of the internet, real-time data streams, and the diversification of connected devices, driven by demands for search services, social networks, mobile commerce, and open collaboration, cloud computing has rapidly emerged. Unlike previous parallel and distributed computing, cloud computing, conceptually, will revolutionize the entire internet model and enterprise management model. Cloud computing refers to the delivery and usage model of IT infrastructure, meaning obtaining necessary resources through the network in an on-demand and easily scalable manner. In a broader sense, cloud computing refers to the delivery and usage model of services, meaning obtaining necessary services through the network in an on-demand and easily scalable manner. These services can be IT and software, internet-related, or other services. Cloud computing is a product of the convergence and development of traditional computer and network technologies such as grid computing, distributed computing, parallel computing, utility computing, network storage technologies, virtualization, and load balancing.

[0035] This application relates to the database aspect of cloud computing technology. A database, simply put, can be viewed as an electronic filing cabinet—a place to store electronic files, where users can perform operations such as adding, querying, updating, and deleting data. A "database" is a collection of data stored together in a certain way, shared by multiple users, with minimal redundancy, and independent of applications. A Database Management System (DBMS) is a computer software system designed to manage databases, generally possessing basic functions such as storage, retrieval, security, and backup. DBMSs can be classified according to the database model they support, such as relational or XML (Extensible Markup Language); or according to the type of computer they support, such as server clusters or mobile phones; or according to the query language used, such as SQL (Structured Query Language) or XQuery; or according to performance priorities, such as maximum scale or maximum operating speed; or other classification methods. Regardless of the classification method used, some DBMSs can cross categories, for example, simultaneously supporting multiple query languages.

[0036] Before implementing the embodiments of this application, the terms involved in the embodiments of this application will be explained first.

[0037] Pipeline Execution Framework

[0038] In database systems, query execution involves many steps, including multiple operators (such as join, selection, and projection operations). Each operator may need to process a large amount of data. These operators can be executed serially, meaning that one operation completes before the next begins. However, this approach can lead to some operations waiting for previous operations to complete, resulting in low computational efficiency. To improve computational efficiency, the Pipeline execution framework was proposed, drawing inspiration from instruction pipelining techniques in computer science. Also known as an execution pipeline or query pipeline, the Pipeline execution framework refers to a strategy in database query processing that organizes and executes the components or operations of the execution plan in a pipelined manner. Using the Pipeline execution framework allows one operation to process the current batch of data while another operation simultaneously begins processing the output of the previous operation. Because the Pipeline execution framework allows different query stages to be processed simultaneously on multiple cores or processors, it significantly improves resource utilization and the parallelism of the overall query processing. Therefore, most database systems currently employ the Pipeline execution framework when executing queries to optimize their performance.

[0039] The Pipeline execution framework includes two operator execution modes:

[0040] Blocking execution: This means that an operation can only be executed after all its inputs have been processed.

[0041] Non-blocking execution: An operator can process the output of an upstream operator immediately without waiting for all inputs to be processed.

[0042] In a pipeline execution framework, each pipeline consists of a set of operators. If the same pipeline can be executed in parallel, then each degree of parallelism forms a Driver. The Driver is the smallest unit of execution and scheduling in the pipeline framework. A Chunk is a data unit; the Driver in a pipeline can write to and read from a Chunk. Typically, the Driver in a pipeline that writes to a Chunk is called the Producer Driver, and the Driver in a pipeline that reads from a Chunk is called the Consumer Driver. For example, Figure 1The illustrated pipeline execution framework comprises two pipelines: Pipeline1 and Pipeline2. Pipeline1 includes Driver1 and Driver2, which respectively function as a Network Reader and a HashAgg Consume. Pipeline2 also includes Driver1 and Driver2, which respectively function as a HashAgg Producer and an Output. Driver1 and Driver2 in Pipeline1 generate chunks and output them to Driver1 and Driver2 in Pipeline2. The two drivers in Pipeline1 are called producer drivers, and the two drivers in Pipeline2 are called consumer drivers.

[0043] Since there is often a significant difference between the speed at which the producer driver generates chunks and the speed at which the consumer driver consumes chunks, a backpressure mechanism is needed to avoid problems such as insufficient memory and system overload.

[0044] Time-slice Scheduling

[0045] Time-slice scheduling is a process scheduling strategy based on time allocation. In a multitasking environment, database systems need to handle multiple concurrent query requests and transaction processing. Time-slice scheduling is one of the methods used by the operating system's scheduler to allocate processor time to these concurrent tasks. In the time-slice scheduling mechanism, the operating system or database management system's scheduler allocates a time period to each running task (process or thread), called a time slice. Each task is allowed to execute within its allocated time slice. Once a task's time slice expires, even if the task has not yet completed, the scheduler will relinquish control of the processor and place it at the end of the ready queue, then schedule another task to run its time slice.

[0046] Using time-slice scheduling has the following advantages:

[0047] The tasks are relatively fair: each task has a chance to get execution time, preventing any single task from monopolizing the processor.

[0048] High responsiveness: By segmenting time slices, the system can respond quickly to interactive tasks.

[0049] Wide applicability: Time-slice scheduling is widely used in various types of operating systems, including real-time systems and general-purpose systems.

[0050] Typically, during time-slice scheduling, each driver transitions between three states: ready, running, and blocked. See also... Figure 2 After a driver is created, it first enters a ready state and is written to a ready queue. Drivers in this ready queue have priorities, and higher-priority drivers get time slices first. After a driver in the ready queue gets a time slice, it enters a running state. During the execution of a driver in the running state, two situations may occur:

[0051] 1) After a period of time slice length, execution ends normally, yielding the time slice and entering the ready queue;

[0052] 2) If a certain condition is met and the device is in a blocked state, it is added to the blocked queue. When another condition is met, it enters the ready queue and is in a ready state.

[0053] Backpressure mechanism

[0054] Backpressure is a common concept in flow control and system design, particularly in reactive programming and network communication. Its primary purpose is to prevent fast producers from overloading slow consumers, leading to overload, data loss, or system crashes. Simply put, backpressure is a feedback control mechanism that allows consumers to signal producers based on their processing capacity, instructing them to slow down or pause sending more data until the consumer has processed the existing data and is ready to receive new data. Backpressure helps maintain system stability and efficiency when there is a mismatch between producer and consumer speeds.

[0055] There are many ways to implement a backpressure mechanism, including but not limited to:

[0056] Pause and resume: Consumers can inform producers to pause data transmission and resume transmission when consumers are ready to receive new data.

[0057] Buffer management: The buffer stores the data sent by the producer. When the buffer capacity reaches a threshold, the producer is notified to slow down or pause sending. Conversely, when a certain amount of data in the buffer has been consumed, the producer is notified to continue sending data.

[0058] Request-response model: Consumers proactively request a certain amount of data from producers based on their processing capabilities, and producers send the corresponding amount of data according to the request.

[0059] In the field of reactive programming, such as systems using the Reactive Streams specification (e.g., RxJava, Reactor, Akka, Streams), backpressure is a core feature. It implements the aforementioned flow control behavior in a standardized way, enabling reactive systems to remain efficient and robust when processing asynchronous data streams. Currently, common backpressure mechanisms in the industry include Flink backpressure, Spark backpressure, and backpressure mechanisms in Java blocking queues, which will be introduced below.

[0060] Flink backpressure mechanism

[0061] Apache Flink is a distributed stream processing framework for handling large-scale data streams. In a distributed stream processing system, computing nodes (tasks, operators, subtasks) process and transmit data in a pipelined manner. Backpressure occurs when downstream operations cannot process data sent by upstream operations in a timely manner. Flink's backpressure mechanism is implemented in its task scheduling system. When the processing speed of a downstream task is lower than the data generation rate of an upstream task, the backpressure mechanism notifies the upstream task to reduce its sending speed, thereby preventing memory overflow and overall system performance degradation. Flink ensures the stability and reliability of stream processing in this way.

[0062] Flink's backpressure is triggered by downstream tasks, and the backpressure process is controlled and managed in the following ways:

[0063] Buffer filling: Flink data transfer is done through a network buffer. When the output buffer of an operation is full, the data is sent to the downstream operation.

[0064] Downstream task signal: If a downstream task is processing data and a new data packet arrives, and the downstream task does not have enough empty data buffer to receive it, it will notify the upstream task to stop sending data.

[0065] Upstream adjustment: When an upstream task receives a backpressure signal, it will stop sending data and store the data in its own buffer. During this process, the upstream task will enter a waiting state until the downstream task finishes processing the existing data and is ready to receive new data.

[0066] Release back pressure: When the downstream task has available space in its buffer, it will notify the upstream task, and then the upstream task can continue to send data.

[0067] Monitoring and Diagnostics: Flink provides monitoring tools that allow users to see if any tasks are under backpressure. For example, through Flink's web UI, users can see which tasks are experiencing backpressure, i.e., their status is marked as "backpressure".

[0068] Using backpressure, Flink can automatically adjust the processing speed between tasks, ensuring that all tasks can work together and avoiding data loss or system crashes due to speed mismatch. At the same time, backpressure is also an important indicator for evaluating and optimizing the performance of stream processing jobs. If a system frequently encounters backpressure, it indicates a potential performance bottleneck, which needs to be addressed by optimizing task parallelism, adjusting buffer size, or improving the computational logic of the tasks.

[0069] Spark backpressure mechanism

[0070] In systems without effective backpressure mechanisms, if the data generation rate consistently exceeds the processing rate, system resources such as memory and cache will be rapidly exhausted, processing latency will increase significantly, and ultimately, the system will crash. In Apache Spark, to prevent data generation from exceeding Spark's processing speed and causing system resource exhaustion, a Spark backpressure mechanism is employed. This mechanism primarily targets Spark Streaming applications, a component of Spark used to process real-time data streams. The principle of the Spark backpressure mechanism is as follows:

[0071] Rate Limiting: Spark Streaming introduces a Dynamic Rate Limiter, which dynamically adjusts the input data rate based on the processing system's capabilities. When starting a job, Spark Streaming allows you to set a maximum receive rate (spark.streaming.receiver.maxRate) and a maximum rate per partition (spark.streaming.kafka.maxRatePerPartition) to control the data input rate.

[0072] Monitoring processing latency: Spark Streaming monitors latency during processing. If the system detects that the processing time exceeds the interval between batch calculations and the consumption speed is insufficient to keep up with the data generation speed, the Spark backpressure mechanism will be activated.

[0073] Rate adjustment: Based on the processing time and latency of several historical batches, Spark Streaming automatically adjusts the data receiving rate by increasing or decreasing the rate to adapt to current processing capacity. This dynamic adjustment helps prevent system overload and maintains processing stability.

[0074] Feedback control: This mechanism is essentially a feedback control system that automatically adjusts the input rate based on real-time performance feedback (such as processing latency) of Spark Streaming jobs, thereby avoiding overload.

[0075] Currently, Spark backpressure is enabled by default in Spark 2.x and later versions. You can explicitly enable backpressure by setting spark.streaming.backpressure.enabled=true.

[0076] Backpressure mechanism in Java blocking queues

[0077] The BlockingQueue class in Java actually includes a built-in backpressure mechanism to control the data flow between producers and consumers, preventing resource exhaustion and providing flow control. Java mainly uses the following two mechanisms to implement backpressure:

[0078] 1. Capacity Limitation: BlockingQueue allows you to specify its capacity at creation time, meaning the queue can only hold a limited number of elements. When the queue is full, threads attempting to add elements will be blocked until space becomes available. This creates a form of backpressure because producers must wait for consumers to remove elements from the queue before adding new elements.

[0079] 2. Blocking Operations: BlockingQueue provides several methods, such as put and take, which block the thread when the queue state does not meet the operational requirements. For example, the put method blocks the thread when the queue is full until space becomes available; the take method blocks the thread when the queue is empty until an element is available. These blocking properties support the natural backpressure on the producer when the consumer is insufficient to handle all the produced data.

[0080] At the underlying implementation level, BlockingQueue may use different synchronization or concurrency mechanisms depending on the implementation type (such as ArrayBlockingQueue, LinkedBlockingQueue, PriorityBlockingQueue, SynchronousQueue, etc.), such as ReentrantLock or Semaphore.

[0081] ReentrantLock: Used for mutually exclusive access to queue elements. In systems such as ArrayBlockingQueue, the lock is used to protect the state of the queue and supports condition variables such as not Full and not Empty to achieve blocking behavior.

[0082] Semaphore: Semaphore can be used to control the number of concurrent accesses to a queue. Although the BlockingQueue interface implementation in Java does not usually use Semaphore directly, some implementations can use the semaphore pattern to control concurrent access to resources.

[0083] Internally, ArrayBlockingQueue uses a lock (ReentrantLock) and two condition variables (usually of type Condition). When a producer attempts to add an element, it will wait on the notFull condition if the queue is full. After a consumer removes an element from the queue, if the queue is no longer full, it will wake up any waiting producers using notFull.signal(). Conversely, when a consumer attempts to remove an element, it will wait on the notEmpty condition if the queue is empty, and after a producer enqueues an element, if the queue is not empty, it will wake up any waiting consumers using notEmpty.signal().

[0084] In summary, Java's BlockingQueue has a built-in backpressure design, and by utilizing synchronization mechanisms such as mutexes and condition variables (which may be similar to the concept of semaphores) in its implementation, it provides flow control functionality between producers and consumers.

[0085] In summary, the aforementioned backpressure mechanisms are suitable for scenarios related to network flow control and do not employ time-slice scheduling strategies. They do not need to consider the impact of scheduling itself and cannot be applied to systems using time-slice scheduling strategies and pipeline execution frameworks. For systems using time-slice scheduling strategies and pipeline execution frameworks, the following issues generally need to be addressed:

[0086] (1) The data read and write speeds of the producer driver and the consumer driver are quite different. The producer driver writes data to the cache much faster than the consumer driver reads data from the cache.

[0087] (2) The data read and write speed of the producer driver and the consumer driver can be measured but cannot be interfered with.

[0088] (3) The scheduling overhead is large when switching between the producer driver and the consumer driver context. If the context switching is performed frequently within a time slice, it will lead to a decrease in system performance.

[0089] (4) The cache size has an upper limit, and the memory space is insufficient.

[0090] To address the problems existing in systems employing time-slice scheduling strategies and pipeline execution frameworks, and in order to enable data processing based on a backpressure mechanism within such systems, this application provides a system employing time-slice scheduling strategies and pipeline execution frameworks. See [link to relevant documentation]. Figure 3 The system includes a producer pipeline, a buffer zone, and a consumer pipeline.

[0091] The producer pipeline has a parallelism of m, consisting of m producer drivers. Each producer driver includes multiple operators, and the last operator can be a LocalExchange operator.

[0092] The consumer pipeline has a parallelism of n, consisting of n consumer drivers. Each consumer driver has a local buffer.

[0093] The number of buffers is the same as the number of consumer drivers, which can be n. Each buffer provides a read / write interface to receive data (chunks) sent downstream by the LocalExchange operator of the upstream producer driver. Each buffer includes a storage queue, which can be an unbounded, non-blocking queue, belonging to a linked list structure. When the LocalExchange operator of the producer driver generates a chunk, it adds the chunk to the head of a buffer's linked list. When a consumer driver needs to read a chunk from that buffer, it reads the chunk from the tail of the linked list and removes the read chunk from the tail. After the consumer driver performs operations on the chunk, it reclaims or destroys the memory occupied by the chunk.

[0094] For systems employing time-slice scheduling and a pipeline execution framework, assuming no memory restrictions and sufficient database memory, *m* producer drivers and *n* consumer drivers can freely read and write to *n* buffers. These drivers operate independently, each using its allocated time slice and then relinquishing it to the pending queue. When a new time slice is allocated, the waiting thread group can remove a producer or consumer driver from the pending queue for the next time slice.

[0095] However, in real-world applications, memory usage is limited. Database memory is finite, and the speed at which the producer driver generates and writes chunks is much greater than the speed at which the consumer driver reads and destroys chunks. This causes the database's memory usage to rise rapidly until phenomena such as out of memory occur.

[0096] To address this issue, the system provided in this application also includes a memory counter (memory_ledger), which is shared by n caches and used to record the total number of bytes of data currently stored in the n caches. By setting the memory counter, the memory level can be determined based on the total number of bytes of data currently stored in the caches recorded by the memory counter, thereby enabling control over the system's data read and write operations. Since it records the total number of bytes, it can reduce the overhead of cache serialization, deserialization, and memory copying, thus improving system performance.

[0097] Furthermore, based on an understanding of the SettableFuture class in Java, this application introduces two state variables: a writable signal (i.e., the first signal) and a readable signal (i.e., the second signal). Both the writable and readable signals are instances of the SettableFuture class. The general concepts of SettableFuture will be briefly introduced below.

[0098] In asynchronous programming, `SettableFuture` represents a signaling mechanism, derived from a class of `Future` objects. A `Future` object signifies that an event will complete in the future. Assuming thread A is the event completer and thread B is the event listener or observer, thread A can check if the event represented by the `Future` object has completed by calling `SettableFuture.isDone`. Thread A can also call `SettableFuture.set(Object)`, passing in any object, to indicate that the event has completed. Thread A also provides the `SettableFuture.get(timeout)` interface. After waiting for the specified timeout, thread B can call `SettableFuture.get(timeout)` to retrieve any object passed in by thread A, thus confirming that the event has completed.

[0099] SettableFuture can register a callback function. Once the event is completed (i.e., SettableFuture.set is called), a certain thread (configurable, usually the thread that calls SettableFuture.set) will retrieve and execute the execution body in the callback function.

[0100] This application embodiment introduces the writable and readable signals, which can precisely control the scheduling process of the producer driver and consumer driver based on memory usage.

[0101] For this system, embodiments of this application provide a data processing method. This method, based on the total number of bytes of data currently stored in the cache recorded by a memory counter and a byte count threshold, allows the producer driver to be added to a blocking queue when the total number of bytes of data currently stored in the cache recorded by the memory counter exceeds the byte count threshold, thereby stopping the writing of data to the cache. When the data in the cache is read empty or the total number of bytes of data currently stored in the cache recorded by the memory counter is 0, the producer driver is removed from the blocking queue and added to a ready queue, and the consumer driver is controlled to be in a waiting state, thereby stopping the reading of data from the cache. After the consumer driver waits for a preset time, a time slice is allocated to the producer driver in the ready queue to put the producer driver into a running state, thereby waking up the consumer driver. Then, the producer driver is controlled to write data to the cache, and the consumer driver is controlled to read data from the cache. When a producer driver is added to the blocking queue, a writable signal can be written to the memory counter. This writable signal has a registered callback function. When the consumer driver reads this writable signal, the registered callback function can be used to remove the producer driver from the blocking queue and add it to the ready queue. When the data in the buffer is read empty or the total number of bytes of data currently stored in the buffer, as recorded by the memory counter, is 0, a readable signal can be written to the memory counter. This readable signal has a registered callback function. When the producer driver reads this readable signal, the registered callback function can be used to wake up the consumer driver, thereby enabling precise control over the scheduling process of the producer driver and the consumer driver. Furthermore, since the producer driver reads data faster than the consumer driver, when the total number of bytes of data currently stored in the cache, as recorded by the memory counter, exceeds the byte count threshold, the producer driver's waiting time is longer. By controlling the producer driver to suspend or yield its time slice, we can prevent the producer driver from waiting in place and occupying system resources, thus reducing system performance. When the cache is empty or the total number of bytes of data currently stored in the cache, as recorded by the memory counter, is 0, the consumer driver's waiting time is shorter because the producer driver reads data faster than the consumer driver. By controlling the consumer driver to wait in place and minimizing the yielding of its time slice, we can reduce scheduling overhead.

[0102] This application provides a data processing method. This method is applied to a system employing a time-slice scheduling strategy and a pipeline execution framework. Taking an electronic device executing this application embodiment as an example, see [link to example]. Figure 4 The method flow provided in this application embodiment includes:

[0103] 401. During any time slice allocated to the consumer driver, when the total number of bytes of data currently stored in the buffer, as recorded by the memory counter, reaches the byte count threshold, the producer driver is added to the blocking queue.

[0104] For systems using time-slice scheduling strategies and Pipeline execution frameworks, electronic devices allocate time slices to each producer driver and each consumer driver. Within the allocated time slice, the producer driver can write data to the buffer, and the consumer driver can read data from the buffer. In this embodiment, because the producer driver relinquishes its allocated time slice when added to the blocking queue and is reallocated a time slice after being added to the ready queue, the producer driver's time slice is constantly changing, while the consumer driver does not relinquish its allocated time slice. To better illustrate the scheduling process of the producer and consumer drivers within a single time slice, this embodiment uses any time slice allocated to the consumer driver as a standard slice for subsequent explanation.

[0105] Within any time slice allocated to the consumer driver, whenever the producer driver writes data to the buffer, it retrieves the first byte count of the written data and increments the total number of bytes currently stored in the buffer by the first byte count in the memory count record. For example, when any producer driver writes a chunk to any LocalBuffer, it calculates the number of bytes occupied by that chunk x1, then executes memory_ledger.addBytes(x1), incrementing the total number of bytes recorded in the memory count record by x1.

[0106] Within any time slice allocated to the consumer driver, whenever the consumer driver reads data from the buffer, it retrieves the second byte count of the read data and decrements the total number of bytes currently stored in the buffer, as recorded by the memory counter, by the second byte count. For example, when any producer driver reads a chunk from any LocalBuffer, it calculates the number of bytes occupied by that chunk x2, then executes memory_ledger.subBytes(x2), decrementing the total number of bytes recorded by the memory counter by x2.

[0107] For systems using a Pipeline execution framework, the operations of the producer driver writing data to the buffer and the operations of the consumer driver reading data from the buffer can be executed in parallel. In this way, the total number of bytes recorded by the memory counter is actually the total number of bytes of actual data stored in the buffer after the read and write operations at a certain moment. For example, at the first moment, the total number of bytes recorded by the memory counter is x0. At the second moment, the number of bytes of data written by the producer driver to the buffer is x3, and the number of bytes of data read by the consumer driver from the buffer is x4. Then, the total number of bytes recorded by the memory counter at the second moment is x0 + x3 - x4.

[0108] In this embodiment, the producer driver's data writing speed is faster than the consumer driver's data reading speed. As read and write operations continue, the amount of data stored in the buffer increases. To avoid insufficient system memory due to excessive data in the buffer, the electronic device monitors the total number of bytes of data currently stored in the buffer, as recorded by the memory counter, within the time slice allocated to the consumer driver. When the total number of bytes of data currently stored in the buffer, as recorded by the memory counter, reaches a threshold, backpressure is triggered, controlling the producer driver to relinquish its allocated time slice and adding it to the blocking queue, thus stopping the producer driver from writing data. The blocking queue stores producer drivers that have stopped writing data due to relinquishing their allocated time slice and also stores consumer drivers that have stopped reading data due to relinquishing their allocated time slice and being blocked. The total number of bytes of data currently stored in the buffer, as recorded by the memory counter, reflects memory usage. A larger total number of bytes of data currently stored in the buffer, as recorded by the memory counter, indicates higher memory usage; conversely, a smaller total number of bytes of data currently stored in the buffer, as recorded by the memory counter, indicates lower memory usage. To visually represent memory usage, this application embodiment refers to the total number of bytes of data currently stored in the cache, as recorded by the memory counter, as the memory level. Correspondingly, the byte count threshold can be called the memory threshold, which can be determined by a person skilled in the art; this application embodiment does not impose specific limitations on it. It should be noted that data takes a certain amount of time (usually tens to hundreds of nanoseconds) from being read by the consumer driver to being destroyed and released from memory. Therefore, the total number of bytes of data currently stored in the cache, as recorded in the memory counter, i.e., the memory level value, does not reflect the actual memory level at that moment. The actual memory level lags behind the memory level recorded by the memory counter.

[0109] Within the time slice corresponding to the consumer driver, when the generator driver yields its allocated time slice based on the backpressure mechanism, the generator driver can be prevented from occupying the time slice, thus improving system performance.

[0110] In this embodiment, when the total number of bytes of data currently stored in the buffer recorded by the memory counter reaches a byte count threshold, the electronic device will also generate a first signal and write the first signal into the memory counter. The first signal can be a writable signal, used to indicate that a first event is in a waiting state; this first event is the event where the producer driver writes data to the buffer. The first signal is registered with a first callback function, which is used to remove the producer driver from the blocking queue and add it to the ready queue after the consumer driver reads the first signal from the memory counter.

[0111] In this embodiment, when the producer driver is added to the blocking queue, the producer driver stops writing data to the buffer, while the operations performed by the consumer driver remain unaffected. During the time slice allocated to the consumer driver, the electronic device continues to control the consumer driver to read data from the buffer. Each time the consumer driver reads data from the buffer, it obtains the third byte count of the read data and decrements the total number of bytes of data currently stored in the buffer (as recorded by the memory counter) by the third byte count. After decrementing the total number of bytes of data currently stored in the buffer (as recorded by the memory counter) by the third byte count, and after the read data has been processed, the data is also cleared from memory.

[0112] 402. When the total number of bytes of data currently stored in the buffer recorded by the memory counter drops to 0 or the data in the buffer is read out, the producer driver is removed from the blocking queue and added to the ready queue, and the consumer driver is kept in a waiting state without yielding the allocated time slice.

[0113] As the consumer driver reads data, the amount of data stored in the buffer decreases, and the total number of bytes of data currently stored in the buffer, as recorded by the memory counter, also decreases. When the total number of bytes of data currently stored in the buffer, as recorded by the memory counter, drops to 0 or the buffer is empty, the producer driver needs to continue writing data to the buffer to prevent abnormal data reads by the consumer driver. To enable the producer driver to write data to the buffer, the electronic device needs to remove the producer driver from the blocking queue and add it to the ready queue. The ready queue is used to store producer or consumer drivers that are in a ready state and waiting to be allocated a time slice. Specifically, when removing the producer driver from the blocking queue and adding it to the ready queue, the consumer driver can be controlled to read a first signal from the memory counter. After reading the first signal, a first callback function is called to remove the producer driver from the blocking queue and add it to the ready queue. In this embodiment, the drivers in the ready queue have different priorities, and time slices are allocated to them in descending order of priority. To ensure that the generator driver retrieved from the blocking queue can be allocated a time slice first to perform data write operations, a higher priority can be set for that generator driver. Of course, to facilitate the management of generator drivers with different priorities, the ready queue can also be divided into different ready sub-queues, each corresponding to a different priority, used to store drivers of different priorities. To ensure that the generator driver retrieved from the blocking queue can be allocated a time slice first, it can be added to the highest priority ready sub-queue.

[0114] After the producer driver is removed from the blocking queue and added to the ready queue, the consumer driver is kept in a waiting state to prevent it from reading data from the buffer. Since the consumer driver's data read speed is much slower than the producer driver's data write speed, the consumer driver's waiting time is shorter. However, frequent calls to the driver incur significant scheduling resource overhead. To avoid frequent calls to the consumer driver, this embodiment does not control the consumer driver to yield its time slice while it is in a waiting state.

[0115] In this embodiment, when the total number of bytes of data currently stored in the buffer, as recorded by the memory counter, drops to 0 or the data in the buffer is read empty, the electronic device will also generate a second signal and write the second signal into the memory counter. The second signal can be a readable signal, which indicates that a second event is in a waiting state. This second event is the event where the consumer driver reads data from the buffer. The second signal is registered with a second callback function, which is used to wake up the consumer driver after the producer driver reads the second signal.

[0116] 403. After the consumer driver's waiting time reaches the preset time, allocate a time slice to the producer driver in the ready queue so that the producer driver is in the running state, and wake up the consumer driver through the producer driver so that the consumer driver is in the running state.

[0117] The preset duration is the maximum duration for which the consumer driver is in a waiting state, and can be set by technical personnel. This preset duration is denoted as t. timeout After the consumer driver has been in a waiting state for a preset period, a time slice can be allocated to the producer driver added to the ready queue, allowing the producer driver to enter the running state. While the producer driver is running, it can wake up the consumer driver to enter the running state. Specifically, the producer driver can read a second signal from a memory counter, call a second callback function, and wake up the consumer driver to enter the running state. Considering that the time slice allocated to the consumer driver is finite, and that the consumer driver may remain within the time slice or yield it as time passes, the methods for waking up the consumer driver differ depending on these two scenarios.

[0118] In one possible implementation, if a consumer driver has yielded its time slice and been added to the blocking queue after waiting for a preset time, it is then removed from the blocking queue and added to the ready queue. A new time slice is allocated to the consumer driver added to the ready queue, allowing it to enter the running state. When adding a consumer driver to the ready queue, a higher priority can be set for that consumer driver to ensure it can be allocated a time slice as quickly as possible.

[0119] In another possible implementation, if the consumer driver is within the time slice after a preset time, the consumer driver is directly switched from the waiting state to the running state.

[0120] 404. Control the producer driver in the running state to write data to the buffer, and control the consumer driver in the running state to read data from the buffer.

[0121] When the producer driver is running, it can control the producer driver to write data to the buffer until the next backpressure is triggered; when the consumer driver is running, it can control the consumer driver to read data from the buffer until the consumer driver yields its time slice, or the total number of bytes of data currently stored in the buffer recorded by the memory counter is 0, or the data in the buffer is read out.

[0122] Figure 5 A flowchart of the data processing method provided in an embodiment of this application is shown. See also: Figure 5 The specific process is as follows:

[0123] 1. A memory threshold Smax (i.e., the number of bytes threshold) is pre-set in the memory counter (memory_ledger). During the time slice allocated to the consumer driver, the producer driver writes data chunks to the buffer, and the consumer driver reads data chunks from the buffer. As the producer driver and consumer driver perform read and write operations, the memory level recorded by the memory counter (i.e., the total number of bytes of data currently stored in the buffer) reaches the memory threshold Smax, which will trigger a backpressure operation. The producer driver creates a writable signal and stores the created writable signal in the memory counter.

[0124] 2. The producer (Driver) relinquishes its allocated time slice and is placed in the blocking queue, thus being suspended.

[0125] 3. The consumer driver continues to read data chunks from the buffer, and at the same time calls memory_ledger.subBytes to reduce the memory water level. When the memory water level recorded by the memory counter drops to 0 or the buffer queue is empty, the consumer driver creates a readable signal and stores the created readable signal in the memory counter.

[0126] 4. The consumer driver retrieves the writable signal from the memory counter and calls writable.set(Object) to trigger the writable signal callback, thereby removing the producer driver from the blocking queue and adding it to the highest priority ready queue.

[0127] 5. The generator (Driver) enters the highest priority ready queue and waits to be allocated a time slice before performing its operation.

[0128] 6. When the consumer driver calls readable.get(timeout), the thread starts to block and wait in place, but does not yield the allocated time slice.

[0129] 7. The consumer driver waits for a maximum of timeout.

[0130] 8. The generator (Driver) acquires a time slice and performs the operation.

[0131] 9. The producer driver reads the readable signal from the memory counter and calls readable.set(Object) to trigger the callback of the readable signal.

[0132] 10. The producer driver wakes up the consumer driver to continue the read operation. If the timeout period expires, the consumer driver yields its time slice and enters the blocking queue. The consumer driver is then removed from the blocking queue and added to the highest-priority ready queue, and a time slice is allocated to it. If the timeout period does not expire, the consumer driver is directly switched from the waiting state to the running state. Then, the producer driver begins producing chunks and writing them to the local buffer. The consumer driver continues to read chunks from the buffer, processes the read chunks, and then destroys the memory occupied by the chunks.

[0133] Considering the overhead of driver scheduling in time-slice scheduling mechanisms, and the need to schedule the relevant producer drivers for a time slice each time backpressure occurs, this overhead includes several parts. Firstly, when a producer driver yields its time slice to enter the blocking or ready queue, it needs to save some of its intermediate state (e.g., context information) and cache current instructions and data to avoid cache misses. Secondly, when a producer driver enters the running state from the ready queue, its context information needs to be reloaded, and cache misses can also occur during runtime. This process is very similar to the context switch process in operating systems. In actual testing of database product instances, it was found that a single scheduling overhead takes approximately several hundred microseconds. If the number of times a producer driver is scheduled exceeds 1000 times / second, or the total scheduling time within 1 second exceeds 100ms, a significant performance regression occurs. Therefore, to improve system performance, it is necessary to strictly control the total number of backpressure events within a time slice to ensure that the total number of backpressure events is within a reasonable threshold. In order to strictly control the total number of backpressure events within a time slice, we will first analyze the influencing factors of the total number of backpressure events within a time slice by combining the read and write operations of the producer driver and consumer driver within a standard time slice.

[0134] In the backpressure execution process, the memory counter `memory_ledger` records the number of bytes written by the producer driver and the number of bytes read by the consumer driver, as well as the duration of each operation by the producer and consumer drivers. By calculation, the speed at which the producer driver writes data to the buffer can be defined as V1, and the speed at which the consumer driver reads data from the buffer can be defined as V2. Assume T is a standard time slice length, T1 is the time from when the producer driver starts writing data to the buffer to when backpressure is triggered, R is the total number of times the producer driver is scheduled or the total number of backpressure operations within a standard time slice, t_timeout is the time the consumer driver waits for the readable signal to trigger a callback, and S is the memory level of the buffer recorded by the memory counter `memory_ledger` at a certain moment. max Let S be the memory threshold. Within a standard time slice, assuming the consumer driver never yields its time slice, the memory level S in the cache changes as follows: Figure 6 As shown.

[0135] See Figure 6Initially, the producer driver and consumer driver run simultaneously. The producer driver writes data to the buffer at a speed of V1, and the consumer driver reads data from the buffer at a speed of V2. At time T1, the memory level of the buffer, as recorded by the memory counter, reaches the set memory threshold S. max Then we can get:

[0136]

[0137] At time T1, the total number of bytes written by the producer (Driver) is: T1V1

[0138] After time T1, the producer driver enters the blocking queue due to backpressure, while the consumer driver continues to read data from the buffer until the memory counter reaches 0 or the buffer queue is empty. At this point, the producer driver is awakened and waits for at most t_timeout. The producer driver, once awakened, begins writing data to the buffer, and the consumer driver is also awakened and begins reading data from the buffer. This process repeats until a standard time slice ends. Because the consumer driver is in a waiting state for a portion of the time, with each wait lasting tens of nanoseconds, the upper limit of data that the consumer driver can read from the buffer within a standard time slice T is:

[0139] ≤V2T

[0140] Then, within a standard time slice T, the total number of back pressure cycles is:

[0141]

[0142] Analysis shows that within a given standard time slice length T, the value of T1 is unstable, but the above formula avoids the impact caused by the instability of T1. The total number of backpressure cycles R is related to the producer driver's data writing speed V1, the consumer driver's data reading speed V2, and the set memory threshold S. max However, within a standard time slice, the speed at which the producer driver writes data to the buffer (V1) and the speed at which the consumer driver reads data from the buffer (V2) are typically fixed. Therefore, to ensure that the total number of backpressure events does not exceed the backpressure event threshold, the memory threshold S needs to be adjusted. max The backpressure count threshold can be the maximum tolerable total number of backpressure counts within a time slice. This threshold can be 800, 1000, etc., with the system default being 1000. Considering the different performance requirements of different users, a database parameter interface can also be reserved for user adjustment.

[0143] Based on the above principles, before performing data read / write operations within the time slice allocated to the consumer driver, it can be determined whether the set byte count threshold can guarantee that the total backpressure count does not exceed the backpressure count threshold, based on the first data writing speed of the producer driver, the second data reading speed of the consumer driver, and the initial byte count threshold. If it cannot be guaranteed, the set initial byte count threshold needs to be adjusted until it can guarantee that the total backpressure count does not exceed the backpressure count threshold. The specific determination process includes:

[0144] The first step is to calculate the total number of backpressure operations of the generator driver within the time slice, based on the first speed at which the generator driver writes data, the second speed at which the consumer driver reads data, and the initial byte count threshold.

[0145] The initial byte count threshold can be 4MB, 8MB, etc., with 8MB being the system default. Specifically, based on the first speed at which the generator driver writes data, the second speed at which the consumer driver reads data, and the initial byte count threshold, the total number of backpressure operations performed by the generator driver within the time slice is calculated, including:

[0146] 1) Calculate the first backpressure time of the generator driver based on the first speed, the second speed, and the initial byte count threshold.

[0147] Assuming the first speed is V1, the second speed is V2, and the initial byte count threshold is S max Then the time of the first back pressure T1 is:

[0148]

[0149] 2) Based on the first speed and the first backpressure time, calculate the first total number of bytes of data written by the producer driver when the first backpressure time is reached.

[0150] By multiplying the first speed by the first backpressure time, we can obtain the first total number of bytes written by the producer driver when the first backpressure time is reached, which is T1V1.

[0151] 3) Based on the length of the time slice and the second speed, calculate the second total number of bytes of data read by the consumer driver within the time slice.

[0152] Considering that the consumer driver is in a waiting state for a portion of the time within a time slice, the second total number of bytes read by the consumer driver within the time slice is ≤ V2T.

[0153] 4) Calculate the ratio of the first total number of bytes and the second total number of bytes to obtain the total number of backpressure cycles.

[0154] By calculating the ratio of the first total number of bytes to the second total number of bytes, the total number of backpressure cycles R can be obtained:

[0155]

[0156] The second step is to adjust the initial byte count threshold when the total number of back pressures exceeds the back pressure count threshold. This byte count threshold ensures that the calculated total number of back pressures does not exceed the back pressure count threshold.

[0157] When the total number of backpressures exceeds the backpressure number threshold, the initial byte count threshold is continuously adjusted. Based on the adjusted byte count threshold, the total number of backpressures is calculated using the method in the first step. If the calculated total number of backpressures does not exceed the backpressure number threshold, the adjusted byte count threshold corresponding to the total number of backpressures is used as the byte count threshold corresponding to the time slice.

[0158] Within the current time slice length, the determined byte count threshold remains unchanged. Within the next time slice length, this byte count threshold can be adjusted. In practical applications of the database instance, it was found that V1 and V2 are relatively stable within a standard time slice, and the threshold is adjusted during the initial S... ma After the value is set, the number of times Smax is dynamically adjusted is not high.

[0159] Additionally, if the set threshold for the number of back pressure cycles is too small, it may cause S max Excessively large values ​​can also lead to out-of-memory errors, causing backpressure to fail. Therefore, in practical applications, the S value is determined based on the runtime memory size of the database instance. max It sets an upper limit value.

[0160] See Figure 7 After setting S max After calculating V1 and V2, within any time slice set for the consumer driver, the producer driver will write data to the buffer at speed V1, and the consumer will read data from the buffer at speed V2. During the read / write operations of the producer and consumer drivers, a memory counter records the total number of bytes of data currently stored in the buffer to control the scheduling of the producer and consumer drivers.

[0161] This application's embodiments are geared towards systems employing time-slice scheduling strategies and Pipeline execution frameworks. They enable data processing based on a backpressure mechanism even when there are significant differences in read / write speeds between the producer and consumer drivers and limited cache memory. Furthermore, by constructing a logical cache area and using a lighter memory counting method, the overhead of serialization, deserialization, and memory copying is avoided. Additionally, based on the time-slice scheduling mechanism, the backpressure frequency is controlled by measuring the read / write speeds of the producer and consumer drivers and adjusting memory thresholds, thus avoiding frequent context switching and improving overall performance.

[0162] All of the above-mentioned optional technical solutions can be combined in any way to form the optional embodiments of this application, and will not be described in detail here.

[0163] Please refer to Figure 8 The illustration shows a schematic diagram of a data processing device provided in an embodiment of this application. This device is applied to a system employing a time-slice scheduling strategy and a pipeline execution framework. The device can be implemented through software, hardware, or a combination of both, and can become all or part of an electronic device. The device includes:

[0164] The first addition module 801 is used to remove the producer driver from the blocking queue and add it to the ready queue when the total number of bytes of data currently stored in the buffer recorded by the memory counter drops to 0 or the data in the buffer is read out during any time slice allocated to the consumer driver. The blocking queue is used to store the producer driver that has stopped writing data due to giving up the allocated time slice and is in a blocked state. The ready queue is used to store the producer driver or consumer driver that is in a ready state and waiting to be allocated a time slice.

[0165] The first control module 802 is used to control the consumer driver to be in a waiting state and not to yield the allocated time slice.

[0166] The allocation module 803 is used to allocate a time slice to the producer driver in the ready queue after the consumer driver's waiting time reaches a preset time, so that the producer driver can be in the running state.

[0167] The wake-up module 804 is used to wake up the consumer driver through the producer driver so that the consumer driver is in a running state.

[0168] The second control module 805 is used to control the running producer driver to write data to the buffer.

[0169] The third control module 806 is used to control the consumer driver in the running state to read data from the cache.

[0170] In another embodiment of this application, the device further includes:

[0171] The first acquisition module is used to acquire the first byte number of the data written whenever the producer driver writes data to the buffer within the time slice allocated to the consumer driver.

[0172] The first record module is used to increase the total number of bytes of data currently stored in the memory count record cache by the first byte.

[0173] The second acquisition module is used to acquire the second byte number of the data read whenever the consumer driver reads data from the buffer.

[0174] The second recording module is used to reduce the total number of bytes of data currently stored in the cache recorded by the memory counter by a second number of bytes;

[0175] The second add module is used to add the producer driver to the blocking queue when the total number of bytes of data currently stored in the cache recorded by the memory counter reaches the byte threshold.

[0176] In another embodiment of this application, the device further includes:

[0177] The first write module is used to write a first signal to the memory counter when the total number of bytes of data currently stored in the buffer recorded by the memory counter reaches the byte count threshold. The first signal is used to indicate that a first event is in a waiting state. The first event is the event in which the producer driver writes data to the buffer. The first signal is registered with a first callback function. The first callback function is used to remove the producer driver from the blocking queue and add it to the ready queue after the consumer driver reads the first signal from the memory counter.

[0178] In another embodiment of this application, the second add module is used to control the consumer driver to read the first signal from the memory counter. After reading the first signal, the first callback function is called to remove the producer driver from the blocking queue and add it to the ready queue.

[0179] In another embodiment of this application, the device further includes:

[0180] The fourth control module is used to control the consumer driver to read data from the buffer within the time slice allocated to the consumer driver after the producer driver is added to the blocking queue.

[0181] The third acquisition module is used to acquire the third byte number of the data read whenever the consumer driver reads data from the buffer.

[0182] The third recording module is used to reduce the total number of bytes of data currently stored in the cache recorded by the memory counter by a third byte until the total number of bytes of data currently stored in the cache recorded by the memory counter drops to 0 or the data in the cache is read out.

[0183] In another embodiment of this application, the device further includes:

[0184] The second write module is used to write a second signal to the memory counter when the total number of bytes of data currently stored in the buffer recorded by the memory counter drops to 0 or the data in the buffer is read empty. The second signal is used to indicate that the second event is in a waiting state. The second event is the event in which the consumer driver reads data from the buffer. The second signal is registered with a second callback function, which is used to wake up the consumer driver after the producer driver reads the second signal.

[0185] In another embodiment of this application, a wake-up module is used to control the producer driver to read a second signal from a memory counter, call a second callback function, and wake up the consumer driver so that the consumer driver is in a running state.

[0186] In another embodiment of this application, the wake-up module is configured to, if the consumer driver has yielded its time slice and been added to the blocking queue after waiting for a preset time, remove the consumer driver from the blocking queue and add it to the ready queue, allocate a new time slice to the consumer driver in the ready queue so that the consumer driver is in the running state; if the consumer driver is within the time slice after the preset time, switch the consumer driver from the waiting state to the running state.

[0187] In another embodiment of this application, the device further includes:

[0188] The calculation module is used to calculate the total number of backpressure operations of the generator driver within the time slice based on the first speed at which the generator driver writes data, the second speed at which the consumer driver reads data, and the initial byte count threshold.

[0189] The adjustment module is used to adjust the initial byte count threshold when the total number of back pressures exceeds the back pressure count threshold, so as to obtain the byte count threshold. The byte count threshold ensures that the calculated total number of back pressures does not exceed the back pressure count threshold.

[0190] In another embodiment of this application, the calculation module is configured to: calculate the first backpressure time of the producer driver based on a first speed, a second speed, and an initial byte count threshold; calculate the first total number of bytes written by the producer driver when the first backpressure time is reached based on the first speed and the first backpressure time; calculate the second total number of bytes read by the consumer driver within the time slice based on the length of the time slice and the second speed; and calculate the ratio of the first total number of bytes and the second total number of bytes to obtain the total number of backpressure cycles.

[0191] Figure 9 This diagram illustrates a structural block diagram of an electronic device 900 provided in an exemplary embodiment of this application. Typically, the electronic device 900 includes a processor 901 and a memory 902.

[0192] The processor 901 can be implemented using at least one of the following hardware forms: DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 901 may also include a main processor and a coprocessor. The main processor is used to process data in the wake-up state; the coprocessor is a low-power processor used to process data in the standby state. In some embodiments, the processor 901 may integrate a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the screen. In some embodiments, the processor 901 may also include an artificial intelligence processor for handling computational operations related to machine learning.

[0193] The memory 902 may include one or more computer-readable storage media, which may be non-transitory computer-readable storage media, such as CD-ROM (Compact Disc Read-Only Memory), ROM, RAM (Random Access Memory), magnetic tape, floppy disk, and optical data storage devices. The computer-readable storage medium stores at least one computer program, which, when executed, enables a data processing method.

[0194] Of course, the aforementioned electronic device may also include other components, such as input / output interfaces and communication components. Input / output interfaces provide an interface between the processor and peripheral interface modules, which can be output devices, input devices, etc. Communication components are configured to facilitate wired or wireless communication between the electronic device and other devices.

[0195] Those skilled in the art will understand that Figure 9 The structure shown does not constitute a limitation on the electronic device 900, and may include more or fewer components than shown, or combine certain components, or use different component arrangements.

[0196] This application provides a computer-readable storage medium storing at least one computer program, which, when executed by a processor, can implement the above-described data processing method.

[0197] This application provides a computer program product, which includes a computer program that, when executed by a processor, can implement the above-described data processing method.

[0198] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0199] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.

Claims

1. A data processing method, characterized by, The method is applied to a system adopting a time slice scheduling strategy and a Pipeline execution framework, and the method comprises the following steps: In any time slice allocated for a consumer driver, when the total number of bytes of data currently stored in a cache area recorded by a memory counter decreases to 0 or the data of the cache area is read empty, a producer driver is taken out of a blocking queue and added to a ready queue, the blocking queue is used to store the producer driver which stops writing data in a blocked state due to giving up the allocated time slice, and the ready queue is used to store the producer driver in a ready state waiting for the allocation of a time slice, and the consumer driver is controlled to be in a waiting state without giving up the allocated time slice. After the waiting duration of the consumer driver reaches a preset duration, a time slice is allocated to the producer driver in the ready queue, so that the producer driver is in a running state, and the consumer driver is woken up by the producer driver, so that the consumer driver is in a running state. The producer driver in the running state is controlled to write data into the cache area, and the consumer driver in the running state is controlled to read data from the cache area.

2. The method of claim 1, wherein, The method further comprises the following steps: In the time slice allocated for the consumer driver, whenever the producer driver writes data into the cache area, a first number of bytes of the written data is acquired, and the total number of bytes of data currently stored in the cache area recorded by the memory counter is increased by the first number of bytes. Whenever the consumer driver reads data from the cache area, a second number of bytes of the read data is acquired, and the total number of bytes of data currently stored in the cache area recorded by the memory counter is decreased by the second number of bytes. When the total number of bytes of data currently stored in the cache area recorded by the memory counter reaches a byte number threshold, the producer driver is added to the blocking queue.

3. The method of claim 2, wherein, The method further comprises the following steps: When the total number of bytes of data currently stored in the cache area recorded by the memory counter reaches the byte number threshold, a first signal is written into the memory counter, the first signal is used to indicate that a first event is in a waiting state, the first event is the event that the producer driver writes data into the cache area, the first signal is registered with a first callback function, and the first callback function is used to take the producer driver out of the blocking queue and add it to the ready queue after the consumer driver reads the first signal from the memory counter.

4. The method of claim 3, wherein, The taking of the producer driver out of the blocking queue and adding it to the ready queue comprises the following steps: The consumer driver is controlled to read the first signal from the memory counter, and after reading the first signal, the first callback function is called to take the producer driver out of the blocking queue and add it to the ready queue.

5. The method of claim 1, wherein, The method further comprises the following steps: When the producer driver is added to the blocking queue, the consumer driver is controlled to read data from the cache area within the time slice allocated to the consumer driver, and each time the consumer driver reads data from the cache area, the third number of bytes of the read data is obtained, the total number of bytes of data currently stored in the cache area recorded by the memory counter is reduced by the third number of bytes, until the total number of bytes of data currently stored in the cache area recorded by the memory counter is reduced to 0 or the data in the cache area is read empty.

6. The method of claim 1, wherein, The method further comprises: When the total number of bytes of data currently stored in the cache area recorded by the memory counter is reduced to 0 or the data in the cache area is read empty, a second signal is written into the memory counter, the second signal is used to indicate that a second event is in a waiting state, the second event is an event of reading data from the cache area by the consumer driver, and the second signal is registered with a second callback function, the second callback function is used to wake up the consumer driver after the producer driver reads the second signal.

7. The method of claim 6, wherein, The method further comprises: The producer driver is controlled to read the second signal from the memory counter, the second callback function is called, and the consumer driver is woken up to make the consumer driver in a running state.

8. The method of claim 7, wherein, The method further comprises: If the consumer driver has given up the time slice after waiting for the preset time and the consumer driver is added to the blocking queue, the consumer driver is taken out of the blocking queue and added to the ready queue, a new time slice is allocated to the consumer driver in the ready queue, and the consumer driver is in a running state, the blocking queue is also used to store the consumer driver that stops reading data in a blocked state due to giving up the allocated time slice, and the ready queue is also used to store the consumer driver in a ready state waiting for allocation of a time slice; If the consumer driver is in the time slice after the preset time, the consumer driver is switched from a waiting state to a running state.

9. The method according to any one of claims 1 to 8, characterized in that, The method further comprises: Based on the first speed of the producer driver writing data, the second speed of the consumer driver reading data, and an initial byte number threshold, a total number of times of back pressure of the producer driver within the time slice is calculated; When the total number of times of back pressure exceeds a back pressure number threshold, the initial byte number threshold is adjusted to obtain the byte number threshold, and the byte number threshold can make the calculated total number of times of back pressure not exceed the back pressure number threshold.

10. The method of claim 9, wherein, The method further comprises: The total number of times of back pressure of the producer driver within the time slice is calculated based on the first speed of the producer driver writing data, the second speed of the consumer driver reading data, and an initial byte number threshold. calculating a first back pressure time of the producer driver based on the first speed, the second speed and the initial byte threshold; calculating a first total byte number of data written by the producer driver when the first back pressure time is reached based on the first speed and the first back pressure time; calculating a second total byte number of data read by the consumer driver within the time slice based on the length of the time slice and the second speed; calculating a total back pressure number by dividing the first total byte number by the second total byte number.

11. A data processing apparatus, characterized by The device is applied to a system adopting a time slice scheduling strategy and a Pipeline execution framework, and the device comprises: a first joining module, configured to, when a total byte number of data currently stored in a buffer recorded by a memory counter falls to 0 or data in the buffer is read empty within any time slice allocated to a consumer driver, take out a producer driver from a blocked queue of the producer driver and add the producer driver to a ready queue, the blocked queue being used to store the producer driver which stops writing data due to being blocked for giving up the allocated time slice, and the ready queue being used to store the producer driver which is in a ready state and waits for allocation of a time slice; a first control module, configured to control the consumer driver to be in a waiting state and not to give up the allocated time slice, an allocation module, configured to allocate a time slice to the producer driver in the ready queue after a waiting duration of the consumer driver reaches a preset duration, so that the producer driver is in a running state; a wake-up module, configured to wake up the consumer driver by the producer driver, so that the consumer driver is in the running state; a second control module, configured to control the producer driver in the running state to write data into the buffer; a third control module, configured to control the consumer driver in the running state to read data from the buffer.

12. An electronic device, comprising: The device comprises a processor and a memory, the memory stores at least one program code, and the at least one program code is used to be called and executed by the processor to implement the data processing method in any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that, The computer readable storage medium stores at least one computer program, and the at least one computer program is executed by the processor to implement the data processing method in any one of claims 1 to 10.

14. A computer program product, characterised in that, The computer program product comprises a computer program, and the computer program is executed by the processor to implement the data processing method in any one of claims 1 to 10.

Images