A dynamic real-time transaction scheduling method and system

Abstract

The application discloses a dynamic real-time transaction scheduling method and system, which breaks the limitation of pre-defined transactions and periodic scheduling, and enables real-time transactions to be dynamically scheduled according to actual requirements without pre-defined transactions through twice priority sorting, ensures that the transactions are completed before the deadline, and significantly improves the flexibility and real-time performance of the system; on the basis of the double loop structure of the database working thread, a multi-version concurrent access strategy and a shadow node strategy based on priority inheritance are introduced, so that the real-time database system can operate more efficiently under complex transaction load, and the real-time response capability is further enhanced; priority allocation and blocking management of the transaction are performed by using the characteristics of the real-time operating system, so that the real-time performance of the real-time operating system is not damaged in the transaction scheduling process, and the efficient response capability of the system is maintained; and the application also provides a system for implementing the method.

Description

Technical Field

[0001] This invention relates to the field of real-time database technology, and specifically to a dynamic real-time transaction scheduling method and system. Background Technology

[0002] Traditional Real-Time Database Management Systems (RTDBs) are widely used in embedded environments, typically relying on predefined transactions and periodic scheduling to meet real-time requirements. These systems ensure timely completion of transactions by predefining transaction types, execution times, and priorities, and employing periodic scheduling algorithms. However, this approach proves significantly inadequate under dynamic and changing system demands, primarily manifesting in insufficient flexibility and low resource utilization. Furthermore, the fixed nature of predefined transactions makes it difficult for the system to adapt to dynamically changing task requirements during runtime, further limiting its adaptability.

[0003] In terms of concurrency control and transaction scheduling, traditional real-time database management systems (RTDBS) often employ locking mechanisms or time-sharing methods. However, in high-concurrency and complex transaction scenarios, these methods are prone to lock contention and priority inversion, thus affecting system response speed and performance, and failing to meet the higher requirements for real-time performance and efficient concurrent processing. Furthermore, transaction scheduling rarely considers the real-time performance of the original real-time operating system (RTOS), often compromising the operating system's real-time capabilities, leading to task scheduling conflicts and increased system latency. Therefore, there is an urgent need for a real-time database management method that can dynamically schedule transactions, optimize resource utilization, adapt to changing needs, and not affect the real-time performance of the real-time operating system (RTOS).

[0004] The invention patent with publication number CN102135980A proposes a method and apparatus for processing real-time transactions. This method dynamically determines whether data items are locked and whether transactions need to be restarted, calculates the optimal sequence of transaction execution and the expected value of the system, and determines the transaction scheduling strategy based on the value comparison. In systems with many concurrent transactions, this method optimizes lock allocation decisions and improves the overall system performance. The corresponding processing apparatus is also disclosed. This solution uses transaction restarts to handle lock conflicts, which may lead to the system executing too many unnecessary transactions. In high-concurrency or complex scenarios, it is easy to cause frequent restarts, affecting the overall system performance and stability, i.e., it cannot cope with high-concurrency scenarios.

[0005] The invention patent with publication number CN105243097A proposes a method for determining the real-time transaction priority and controlling concurrency in aerospace telemetry and control databases. This method allocates priority based on transaction value and optimizes transaction execution in high-concurrency environments through improved priority inheritance and deadlock handling algorithms, ensuring that hard real-time transactions take priority, improving the on-time completion rate of soft real-time transactions, and reducing the transaction failure rate. However, this solution does not fully consider the real-time performance of the real-time operating system, which may affect the real-time scheduling of the external real-time operating system. At the same time, it does not optimize the multiple priority inheritance problem, which may lead to excessive resource consumption in complex multi-inheritance scenarios and affect the overall system performance. Summary of the Invention

[0006] To overcome the shortcomings of the existing technology, the present invention aims to provide a dynamic real-time transaction scheduling method and system. This method breaks through the limitations of predefined transactions and periodic scheduling. Through two priority sorting processes, real-time transactions can be dynamically scheduled according to actual needs without the need for predefined transactions, ensuring that transactions are completed before their deadlines, thereby significantly improving the system's flexibility and real-time performance. Simultaneously, based on the dual-loop structure of the database worker threads, a multi-version concurrency access strategy and a priority inheritance-based shadow node strategy are introduced, enabling the real-time database system to operate more efficiently under complex transaction loads and further enhancing real-time response capabilities. By utilizing the characteristics of the real-time operating system to allocate priorities and manage blocking for transactions, the real-time performance of the real-time operating system is not compromised during transaction scheduling, maintaining the system's high-efficiency response capabilities.

[0007] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0008] A dynamic real-time transaction scheduling method includes the following steps:

[0009] Step 1: The transaction production thread assigns priority and deadline to the transaction, and inserts the transaction into the transaction queue after converting it into a set of bytecode instructions;

[0010] Step 2: The transaction queue is sorted for the first time according to the priority of the transactions inserted in Step 1, and then sorted for transactions of the same priority a second time using a custom value function to select the transaction with the highest priority.

[0011] Step 3: The database worker threads concurrently execute the highest priority transaction from Step 2 using a double loop structure;

[0012] Step 4: Based on the execution status of the highest priority transaction in Step 3, the database worker thread commits or rolls back the transaction.

[0013] Furthermore, step 2 specifically includes:

[0014] The highest priority transaction is obtained by scanning the head node of the transaction queue after the inserted transaction. If the highest priority transaction is unique, then the transaction is returned as the highest priority transaction.

[0015] If not unique, scan all transactions with the same primary priority one by one from the head of the queue, use a custom value function to compare the secondary priorities of all transactions with the same primary priority, and select the transaction with the highest secondary priority as the final highest priority transaction.

[0016] Furthermore, the custom value function is the earliest deadline first (EDF) scheduling method.

[0017] Furthermore, step 3 specifically includes:

[0018] The database worker thread's dual-loop structure includes an outer loop and an inner loop;

[0019] The outer loop continuously reads the highest priority transaction from the transaction queue, while the inner loop executes the transaction's bytecode instructions according to the transaction's program counter and checks the preemptive scheduling flag in the transaction queue.

[0020] When the preemptive scheduling flag is true, preemptive scheduling is triggered, the inner loop ends, the outer loop is re-entered to read the current highest priority transaction, and the inner loop is entered to execute its bytecode instructions.

[0021] The preempted transaction will save its context information in the register set, temporarily suspend it, and wait for rescheduling for execution.

[0022] Furthermore, in step 3, when the database worker thread concurrently executes the highest-priority transaction from step 2 using a double-loop structure, a multi-version concurrency access strategy is used to manage the acquisition and release of locks during execution, specifically:

[0023] Divide the database storage space into a consistent version and a working version;

[0024] Read lock requests apply to the consistent version, while write lock requests apply to the working version.

[0025] Read locks allow multiple transactions to acquire read locks on the same page simultaneously;

[0026] A write lock allows only one transaction to acquire a write lock on a specific data page and modify the data in the working version.

[0027] A commit lock is acquired by upgrading a write lock to a commit lock;

[0028] If a data page already has a read lock, the lock escalation will be blocked.

[0029] If a lock commit request is upgraded, read lock requests for that data page will be blocked until the lock commit completely releases the workspace.

[0030] Furthermore, in step 3, when the database worker thread concurrently executes the highest-priority transaction from step 2 using a double-loop structure, if transaction blocking occurs, priority inheritance is implemented through the shadow node method, specifically:

[0031] A new node is inserted into the transaction queue. The transaction and register states of the new node are the same as those of the blocked transaction, and its priority is inherited from the blocked transaction. When the shadow node releases the lock that caused the blocking, the system will remove the shadow node from the transaction queue.

[0032] Furthermore, in step 4, when the database worker thread commits the transaction, it synchronizes the modifications made by the transaction in the workspace to the consistency space, specifically as follows:

[0033] When a transaction is ready to be committed, the write lock is upgraded to a commit lock;

[0034] Before committing, check for potential conflicts with read locks from other transactions during the commit lock escalation process;

[0035] Once the lock upgrade is successfully committed, the changes in the workspace will be written to the consistency space.

[0036] After the transaction is committed, the read locks, write locks, and commit locks held by the transaction are released, and the transaction's workspace is cleaned up to free up system resources for subsequent transactions.

[0037] Send a semaphore to the transaction production thread indicating that the transaction has been committed.

[0038] Furthermore, in step 4, when the database worker thread rolls back the transaction, it undoes the modifications made to the data during the transaction's execution and releases resources, specifically as follows:

[0039] Clean up the transaction's workspace and undo all modifications made to the data within the workspace by the transaction.

[0040] After the workspace is cleaned up, release the read locks and write locks held by the firm;

[0041] Send a signal to the transaction production thread indicating that the transaction commit has failed.

[0042] Furthermore, the transaction producer thread and the database worker thread adopt a publish-subscribe model. The transaction producer thread, as the publisher, puts transaction requests into the transaction queue, and the database worker thread, as the consumer, retrieves them from the queue and executes the transactions.

[0043] A dynamic real-time transaction scheduling system, comprising:

[0044] Transaction production module: The transaction production thread assigns priority and deadline to transactions, and inserts the transactions into the transaction queue after converting them into a set of bytecode instructions;

[0045] Transaction Management Module: The transaction queue is sorted first according to the priority of the inserted transactions, and then sorted a second time for transactions of the same priority using a custom value function;

[0046] Transaction execution module: Database worker threads use a double loop structure to concurrently execute the highest priority transaction;

[0047] Transaction notification module: Based on the execution status of the highest priority transaction, the database worker thread commits or rolls back the transaction.

[0048] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0049] 1. The practical queue of this invention performs two sorting operations. The first sorting depends on the priority assigned to the transaction by the transaction production thread, which is used to ensure that the execution order of transactions is consistent with the priority of operating system tasks and to guarantee the real-time performance of the operating system. The second sorting is dynamically calculated based on a custom value function. The custom value function can be dynamically adjusted according to the specific needs of the user, thereby giving the system greater flexibility. By performing two priority sorting operations, the real-time performance of the operating system is guaranteed to the maximum extent. At the same time, the scheduling flexibility and transaction execution efficiency of the system are improved by dynamic adjustment.

[0050] 2. This invention continuously reads the highest priority transaction from the transaction queue through a dual-loop structure, ensuring that the entire system can respond to changes in the transaction queue in real time; at the same time, through a preemptive scheduling mechanism, the system can prioritize the execution of newly arrived high-priority transactions, maximizing the guarantee of real-time requirements.

[0051] 3. The database worker threads of this invention adopt a multi-version concurrency access strategy, support read-write separation, and significantly reduce resource consumption during transaction commit and rollback processes, thereby improving the concurrent processing capability of transactions.

[0052] 4. By implementing the priority inheritance strategy in the form of shadow nodes, this invention not only effectively reduces the resource consumption caused by thread switching, but also supports multiple inheritance, greatly improving the ability of the real-time database management system to handle blocking in complex transaction scenarios.

[0053] 5. This invention adopts a publish-subscribe model, where the transaction production thread acts as the publisher and puts transaction requests into the transaction queue, and the database worker thread acts as the consumer and retrieves and executes the transactions from the queue. This enables unified management of all database transaction requests, making operation scheduling more flexible. Blocking between transactions only requires saving the state and suspending, without actually switching threads, which greatly simplifies the scheduling logic.

[0054] In summary, the real-time transaction scheduling method of this invention overcomes the limitations of predefined transactions and periodic scheduling. Through two priority sorting processes, real-time transactions can be dynamically scheduled according to actual needs without the need for predefined transactions, ensuring that transactions are completed before their deadlines, thereby significantly improving the system's flexibility and real-time performance. Furthermore, based on the dual-loop structure of the database worker threads, a multi-version concurrency access strategy and a priority inheritance-based shadow node strategy are introduced, enabling the real-time database system to operate more efficiently under complex transaction loads and further enhancing real-time responsiveness. By utilizing the characteristics of the real-time operating system to allocate priorities and manage blocking for transactions, the real-time performance of the real-time operating system is not compromised during transaction scheduling, maintaining the system's high-efficiency responsiveness. Attached Figure Description

[0055] Figure 1 This is a flowchart of the dynamic real-time transaction scheduling method of the present invention.

[0056] Figure 2 This is a diagram of the double loop structure of the database worker thread in this invention.

[0057] Figure 3 This is a diagram illustrating a preemptive scheduling method of the present invention.

[0058] Figure 4 This is an example diagram of an implementation of the shadow node of the present invention.

[0059] Figure 5 This is a schematic diagram of the consistency space and working space in the multi-version concurrent access control of this invention.

[0060] Figure 6 This is a schematic diagram of the publish-subscribe model of this invention.

[0061] Figure 7 This describes the SQLite response time for tasks of different priorities on the RT-Thread platform.

[0062] Figure 8 Box plot of SQLite response time for different priority tasks on the RT-Thread platform.

[0063] Figure 9The method of this invention is used to improve the response time of a real-time transaction scheduling system built based on the method of this invention for tasks of different priorities on the RT-Thread platform.

[0064] Figure 10 A box diagram of the response time of a real-time transaction scheduling system based on the method of this invention for requesting tasks of different priorities on the RT-Thread platform. Detailed Implementation

[0065] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments:

[0066] See Figure 1 A dynamic real-time transaction scheduling method includes the following steps:

[0067] Step 1: The transaction production thread assigns priority and deadline to the transaction, and inserts the transaction into the transaction queue after converting it into a set of bytecode instructions;

[0068] When assigning priorities to transactions, the system allocates priorities, while deadlines are allocated based on user requirements to constrain transaction completion times. The bytecode instruction set of a transaction contains the sequence of operations required for that transaction and is dynamically generated by the transaction production thread according to transaction needs.

[0069] The transaction production thread is also responsible for initializing the execution context of each transaction in the transaction queue, specifically including: creating the transaction's register set to store temporary variables and states during transaction execution; initializing the transaction's program counter (PC pointer) to record the execution position of the transaction's bytecode; inserting the initial state of the transaction into the transaction queue and marking it as "pending scheduling".

[0070] When a transaction is converted into a set of bytecode instructions and inserted into the transaction queue, it enters a blocking state because the transaction request is designed to be synchronous. This blocking state is used to wait for and listen for the semaphore signal from the database worker thread indicating that the transaction has been completed. Once the transaction is completed or aborted, the transaction producer thread will be notified by the semaphore signal issued by the subsequent database worker thread and will be responsible for cleaning up the transaction's resources while freeing up queue space for the generation of subsequent transactions.

[0071] Step 2: The transaction queue is sorted for the first time according to the priority of the transactions inserted in Step 1, and then sorted for transactions of the same priority a second time using a custom value function to select the transaction with the highest priority.

[0072] In this embodiment, the transaction queue is the core module in real-time transaction management. It is responsible for storing all transactions to be executed and dynamically maintaining the priority order of transactions in the queue.

[0073] Furthermore, step 2 specifically includes:

[0074] The highest priority transaction is obtained by scanning the head node of the transaction queue after the inserted transaction. If the highest priority transaction is unique, then the transaction is returned as the highest priority transaction.

[0075] If not unique, scan all transactions with the same primary priority one by one from the head of the queue, use a custom value function to compare the secondary priorities of all transactions with the same primary priority, and select the transaction with the highest secondary priority as the final highest priority transaction.

[0076] In this embodiment, the transaction queue is sorted twice. The first sort depends on the priority assigned to the inserted transaction by the transaction production thread, which is used to ensure that the execution order of transactions is consistent with the priority of operating system tasks and to ensure the real-time performance of the operating system.

[0077] The second ranking is dynamically calculated based on a custom value function. This function can be dynamically adjusted according to the user's specific needs, thus giving the system greater flexibility. For example, priorities can be calculated based on dynamically changing factors such as the importance of the transaction, the urgency of the deadline, and resource requirements. Through this design, the system can dynamically prioritize transactions with the same primary priority, optimizing transaction scheduling efficiency.

[0078] The aforementioned two-level priority mechanism maximizes the real-time performance of the operating system while also improving the system's scheduling flexibility and transaction execution efficiency through dynamic adjustments.

[0079] Furthermore, the custom value function is the earliest deadline first (EDF) scheduling method.

[0080] Common custom value functions include: Earliest Deadline First (EDF), which sorts transactions by their deadlines, with the earliest deadline having higher priority and processing the most urgent transactions first; First-Come, First-Served (FIFO), which sorts transactions according to the time they arrive in the queue, ensuring that transactions are processed in the order of arrival; and Round-Robin (RR), which allocates processing time to transactions of the same priority in a fixed time slice, cyclically scheduling transactions in the queue to ensure fairness in resource allocation. This embodiment uses the Earliest Deadline First (EDF) scheduling method, which sorts transactions by their deadlines.

[0081] Step 3: The database worker threads concurrently execute the highest priority transaction from Step 2 using a double loop structure;

[0082] In this embodiment, the database worker thread, also known as the consumer virtual machine, is a program-level virtual machine and the core execution mechanism of the database worker thread. It is responsible for reading the highest priority transactions from the transaction queue and executing their bytecode instructions in sequence.

[0083] Furthermore, step 3 specifically includes:

[0084] The database worker thread's dual-loop structure includes an outer loop and an inner loop;

[0085] The outer loop continuously reads the highest priority transaction from the transaction queue, while the inner loop executes the transaction's bytecode instructions according to the transaction's program counter and checks the preemptive scheduling flag in the transaction queue.

[0086] When the preemptive scheduling flag is true, preemptive scheduling is triggered, the inner loop ends, the outer loop is re-entered to read the current highest priority transaction, and the inner loop is entered to execute its bytecode instructions.

[0087] The preempted transaction will save its context information in the register set, temporarily suspend it, and wait for rescheduling for execution.

[0088] This embodiment continuously reads the highest priority transaction from the transaction queue through a dual-loop structure, ensuring that the entire system can respond to changes in the transaction queue in real time; at the same time, through a preemptive scheduling mechanism, the system can prioritize the execution of newly arrived high-priority transactions, maximizing the guarantee of real-time requirements.

[0089] like Figure 2 This embodiment uses a dual-loop structure. The outer loop is an infinite loop that continuously reads the highest-priority transaction from the transaction queue. The inner loop is a bytecode execution loop. When the transaction switching flag (State) is false, the database worker thread uses a switch statement to determine the next atomic operation to execute based on the bytecode instruction pointed to by the program counter in the transaction structure. After each instruction is executed, the program counter increments to point to the next bytecode instruction to be executed. If the transaction switching flag (State) is true, preemptive scheduling is triggered, and the highest-priority transaction is read from the transaction queue again and processed.

[0090] like Figure 3 In the preemptive scheduling example of this embodiment, when the database worker thread DBWorkThread is executing transaction T2 initiated by the second transaction producer thread WorkThread2 with a priority of 2, the first transaction producer thread WorkThread1 with a higher priority initiates transaction T1. Since the priority of transaction T1 is higher than that of transaction T2, the transaction switching flag State is set to true, so transaction T2 is interrupted and transaction T1 begins to execute. In order to ensure that transaction T1 is processed first, the database worker thread DBWorkThread will adjust its own priority according to the priority of transaction T1 to match the priority of transaction T1.

[0091] Furthermore, in step 3, when the database worker thread concurrently executes the highest-priority transaction from step 2 using a double-loop structure, a multi-version concurrency access strategy is used to manage the acquisition and release of locks during execution, specifically:

[0092] Divide the database storage space into a consistent version and a working version;

[0093] Read lock requests apply to the consistent version, while write lock requests apply to the working version.

[0094] Read locks allow multiple transactions to acquire read locks on the same page simultaneously;

[0095] A write lock allows only one transaction to acquire a write lock on a specific data page and modify the data in the working version.

[0096] A commit lock is acquired by upgrading a write lock to a commit lock;

[0097] If a data page already has a read lock, the lock escalation will be blocked.

[0098] If a lock commit request is upgraded, read lock requests for that data page will be blocked until the lock commit completely releases the workspace.

[0099] By using the aforementioned multi-version concurrent access strategy to manage the acquisition and release of locks during execution, read-write separation is supported, significantly reducing resource consumption during subsequent commit and rollback processes, thereby improving the concurrent processing capability of transactions.

[0100] Furthermore, in step 3, when the database worker thread concurrently executes the highest-priority transaction from step 2 using a double-loop structure, if transaction blocking occurs, priority inheritance is implemented through the shadow node method, specifically:

[0101] A new node is inserted into the transaction queue. The transaction and register states of the new node are the same as those of the blocked transaction, and its priority is inherited from the blocked transaction. When the shadow node releases the lock that caused the blocking, the system will remove the shadow node from the transaction queue.

[0102] The introduction of shadow nodes avoids random modifications to the transaction queue, facilitates handling multiple inheritance, and avoids the resource consumption of thread switching caused by traditional priority inheritance, enabling priority inheritance to be executed efficiently in complex transaction scheduling.

[0103] like Figure 4This invention implements a priority inheritance strategy for shadow nodes. In the current transaction queue, transactions T2, T3, and T4 are arranged in descending order of priority, where transaction T2 is the currently executing transaction. However, the execution of transaction T2 is blocked by transaction T4. According to the priority inheritance mechanism, transaction T4 should temporarily inherit the priority of transaction T2 to ensure that the operation is completed as soon as possible and the resources blocking T2 are released. To avoid frequent modification of nodes in the transaction queue, this invention uses a shadow node mechanism. A new shadow node is inserted after transaction T2, and the transaction pointer of this node points to T4. When transaction T4 releases its resources, the shadow node is deleted, eliminating the need for the complex operation of deleting and re-inserting transaction T4 twice. This simplifies the management of the transaction queue while ensuring the efficient execution of the priority inheritance mechanism.

[0104] Step 4: Based on the execution status of the highest priority transaction in Step 3, the database worker thread commits or rolls back the transaction.

[0105] Furthermore, in step 4, when the database worker thread commits the transaction, it synchronizes the modifications made by the transaction in the workspace to the consistency space, specifically as follows:

[0106] When a transaction is ready to commit, the write lock is upgraded to a commit lock. During the upgrade process, other transactions will be blocked from acquiring read locks on the same data object, ensuring that the data consistency space is not affected by other transactions during the commit operation and avoiding inconsistent data views during the commit process.

[0107] Before committing, a check is performed to check for potential conflicts with read locks of other transactions during the commit lock escalation process. If other transactions hold read locks on the same data object, the commit lock escalation will be blocked, and the commit operation will continue only after the read locks are released.

[0108] Once the lock upgrade is successfully committed, the changes in the workspace are written to the consistency space. This process needs to ensure the atomicity of the operation and the consistency of the data to prevent incomplete data due to partial changes being written.

[0109] After the transaction is committed, the read locks, write locks, and commit locks held by the transaction are released, and the transaction's workspace is cleaned up to free up system resources for subsequent transactions.

[0110] Send a semaphore signaling the completion of the transaction commit to the transaction producer thread to notify it that the transaction has been successfully committed; the transaction producer thread determines that the transaction has been successfully executed based on the semaphore signal it has received.

[0111] Furthermore, in step 4, when the database worker thread rolls back the transaction, it undoes the modifications made to the data during the transaction's execution and releases resources, specifically as follows:

[0112] Clean up the transaction's workspace and undo all modifications made to the data within the workspace by the transaction.

[0113] After the workspace is cleaned up, release the read locks and write locks held by the firm;

[0114] A semaphore indicating a failed transaction commit is sent to the transaction producer thread. The transaction producer thread determines that the transaction execution has failed based on the semaphore indicating a completed transaction commit that it has heard.

[0115] like Figure 5 As shown, the relationship between the consistency space and the working space in this embodiment is clearly illustrated. The consistency space is the storage area for all data in the real-time database, providing a globally consistent view of the system data. The working space, on the other hand, is used to store copies of modified data objects during transaction execution. It is maintained separately for each transaction to ensure transaction isolation and protection of the original data. Each page in the consistency space can only have one copy in the working space; that is, to generate a copy of a page in the consistency space, a write lock on that page must first be acquired. During transaction execution, access to data objects must follow the corresponding locking mechanism. Before reading or writing a data object, a transaction must first acquire the corresponding read lock or write lock. Read operations on data objects are performed directly from the consistency space, ensuring that the latest globally consistent data is read. Write operations on data objects update the value of that data object in the working space and do not directly affect the data in the consistency space until the transaction is committed, at which point the modifications in the working space are merged into the consistency space. This design guarantees the concurrent execution capability of transactions while maintaining data consistency and isolation.

[0116] Furthermore, the transaction producer thread and the database worker thread adopt a publish-subscribe model. The transaction producer thread, as the publisher, puts transaction requests into the transaction queue, and the database worker thread, as the consumer, retrieves them from the queue and executes the transactions.

[0117] In real-time database transaction management, transaction execution can adopt two modes: the publish-subscribe model and the local execution model. A significant advantage of the publish-subscribe model over the local execution model is its ability to uniformly manage all database transaction requests, making operation scheduling more flexible. In this model, since all database operations are completed by a single database worker thread, blocking between transactions only requires saving the state and suspending the transaction, without actually switching threads, which greatly simplifies the scheduling logic. Furthermore, lock management is handled by a single thread, making lock design more flexible and management more convenient.

[0118] like Figure 6The publish-subscribe model used in this embodiment manages the execution and scheduling of real-time transactions within the entire real-time transaction scheduling framework. This model fully considers the dynamism of real-time systems and the efficiency of task scheduling. In this model, the transaction producer thread (WorkThread) acts as the publisher, placing transaction requests into the transaction queue. These requests include the transaction's priority, deadline, and other key execution parameters. Simultaneously, the database worker thread acts as the consumer, continuously subscribing to real-time transactions in the transaction queue and processing them in descending order of priority. Through the collaborative work of the transaction producer thread, the transaction queue, and the database worker thread, efficient management and scheduling of real-time transactions are achieved.

[0119] A dynamic real-time transaction scheduling system, comprising:

[0120] Transaction production module: The transaction production thread assigns priority and deadline to transactions, and inserts the transactions into the transaction queue after converting them into a set of bytecode instructions;

[0121] Transaction Management Module: The transaction queue is sorted first according to the priority of the inserted transactions, and then sorted a second time for transactions of the same priority using a custom value function;

[0122] Transaction execution module: Database worker threads use a double loop structure to concurrently execute the highest priority transaction;

[0123] Transaction notification module: Based on the execution status of the highest priority transaction, the database worker thread commits or rolls back the transaction.

[0124] The application effects of this invention will be described in detail below in conjunction with real-time testing.

[0125] In embedded real-time systems, databases need to maintain efficient transaction scheduling capabilities in a multi-task concurrent environment to meet the real-time requirements of tasks with different priorities. Traditional relational databases typically use sequential or lock contention scheduling methods when processing transactions, while the real-time transaction scheduling system built based on the method of this invention introduces a priority scheduling mechanism to optimize the execution order of transactions and ensure timely response to critical tasks.

[0126] This test, based on the RT-Thread platform, simulates high, medium, and low priority tasks and measures the response time of transactions with different priorities to evaluate the database's scheduling performance in a multi-tasking environment. To comprehensively analyze the database's scheduling characteristics, the test was conducted on SQLite and a real-time transaction scheduling system built based on the method of this invention, observing their transaction execution under the same load. By comparing the transaction response time and scheduling strategies of different databases, this test will provide a performance analysis basis for the priority scheduling mechanism of the transaction scheduling of this invention.

[0127] To evaluate the response time of SQLite and the real-time transaction scheduling system built based on the method of this invention in handling transactions of different priorities on the RT-Thread platform, this test conducted 150 batches of experiments, testing the execution of high, medium, and low priority transactions. The response time of each batch was recorded, and the performance of different priority transactions in a multi-task concurrent environment was displayed using a scatter plot.

[0128] like Figure 7 Results of SQLite response times for tasks of different priorities on the RT-Thread platform:

[0129] When executing tasks of three priorities concurrently, SQLite employs a mutual exclusion mechanism for transactions containing write operations. Therefore, regardless of which priority task acquires execution rights for SQLite first, the SQLite requests of the other two tasks will be blocked. After the current task completes its execution, RT-Thread will wake up the relatively higher-priority task to request SQLite. Thus, the execution order of concurrent tasks may be high-medium-low, medium-high-low, or low-high-medium.

[0130] exist Figure 7 As shown, there are three response time bands. The fast response time band includes high, medium, and low priority transactions. In other words, in concurrent requests, the response time of the transaction that first acquires execution rights in SQLite will fall within this band. Because high-priority transactions have higher priority, their response times will only appear in the fast and medium response time bands. Low-priority transactions have lower priority, and their response times will only appear in the fast and slow response time bands. Medium-priority transactions will appear in all three time bands. To more clearly illustrate the response time distribution of the three priority transaction types, the following diagram illustrates this. Figure 8 The box diagram is shown below:

[0131] The length of the boxes in a box diagram represents, to some extent, the concentrated range of data. In the SQLite test scenario, the lengths of low and medium priority boxes span three response time bands, indicating significant response time fluctuations. High-priority transactions, initiated by high-priority tasks in the RTthread and having priority scheduling rights, have relatively shorter boxes, concentrated only in the low to medium response time bands. It can be seen that SQLite's real-time response capability in a real-time operating system is generally poor, with large response time fluctuations.

[0132] from Figure 9As can be seen, the response time of the real-time transaction scheduling system built based on the method of this invention is also concentrated in three time bands. However, unlike the response time distribution of SQLite, the response time of each priority task exhibits a more distinct stratification. Specifically, the response time of high-priority tasks only appears in the fast response time band, the response time of medium-priority tasks only appears in the medium-speed response time band, and the response time of low-priority tasks falls entirely in the low-speed response time band.

[0133] like Figure 10 As shown in the figure, it can be clearly seen from the response time box diagrams of the real-time transaction scheduling system built based on the method of the present invention for different priority task requests under the RT-Thread platform that the box diagrams of low, medium and high priority tasks are significantly shorter than the box diagram of SQLite, and the box diagrams of each priority task are only distributed on one response time band. This indicates that the transaction response time of the real-time transaction scheduling system built based on the method of the present invention is more stable and the data distribution range is more concentrated.

[0134] To further quantify the transaction scheduling stability of SQLite and the real-time transaction scheduling system built based on the method of this invention on the RT-Thread platform, the response time variance of transactions with three priorities was calculated. A larger variance indicates greater fluctuation in transaction response time and less stable real-time performance; a smaller variance indicates more concentrated transaction execution time and a more deterministic scheduling mechanism. Table 1 below lists the response time variance of SQLite and the real-time transaction scheduling system built based on the method of this invention for high, medium, and low priority transactions:

[0135] Table 1. Comparison of response time variance between SQLite and the real-time transaction scheduling system built based on the method of this invention for transactions of different priorities.

[0136]

[0137] As shown in Table 1, the response time variance of SQLite under different transaction priorities is significantly higher than that of the real-time transaction scheduling system built based on the method of this invention. In particular, the variance for low-priority transactions reaches as high as 358,340.5, indicating that its response time fluctuates greatly and is significantly affected by lock contention and scheduling strategies. In contrast, the variance of the real-time transaction scheduling system built based on the method of this invention is significantly reduced, with the variance for low-priority transactions being only 97.08, indicating that its execution time is more stable and less susceptible to interference from high-priority transactions. Furthermore, the variance for high-priority transactions in SQLite is 94,872.19, while that in the real-time transaction scheduling system built based on the method of this invention is only 521.76, indicating that the scheduling mechanism of the real-time transaction scheduling system built based on the method of this invention can better ensure the execution stability of high-priority transactions and reduce the uncertainty of response time.

[0138] This characteristic indicates that the real-time transaction scheduling system built based on the method of this invention can strictly schedule tasks according to their priorities on the RT-Thread platform. High-priority tasks can acquire execution rights and complete transactions faster, while medium- and low-priority tasks are completed sequentially over a longer time range. This strict priority division contrasts sharply with the randomness and volatility of SQLite's transaction processing, verifying the deterministic and real-time advantages of the real-time transaction scheduling system built based on the method of this invention in task scheduling.

[0139] The above embodiments are merely detailed descriptions of the present invention, but the present invention is not limited to the above embodiments. Any modifications, substitutions, and changes made to the present invention within the spirit and scope of the claims are within the scope of protection of the present invention.

Claims

1. A dynamic real-time transaction scheduling method, characterized by: The method comprises the following steps: Step 1: a transaction production thread gives priority and a deadline to a transaction, converts the transaction into a bytecode instruction set, and inserts the transaction into a transaction queue; Step 2: the transaction queue sorts the transaction according to the priority of the transaction inserted in step 1 for the first time, and sorts the transactions with the same priority according to the earliest deadline first scheduling method for the second time, and selects the transaction with the highest priority; Step 3: a database worker thread concurrently executes the transaction with the highest priority in step 2 by using a double-loop structure; The double-loop structure of the database worker thread comprises an outer loop and an inner loop; The outer loop continuously reads the transaction with the highest priority from the transaction queue, and the inner loop executes the bytecode instruction of the transaction according to the program counter of the transaction and checks a preemption scheduling flag in the transaction queue; When the preemption scheduling flag is true, preemption scheduling is triggered, the inner loop ends, the outer loop is re-entered to read the transaction with the highest priority, and the inner loop executes the bytecode instruction of the transaction; The preempted transaction saves context information in a register group, is temporarily suspended, and waits for re-scheduling and execution; In step 3, the database worker thread concurrently executes the transaction with the highest priority in step 2 by using the double-loop structure, and acquires and releases locks in the execution process by using a multi-version concurrency control strategy, specifically as follows: The database storage space is divided into a consistent version and a working version; A read lock request acts on the consistent version, and a write lock request acts on the working version; The read lock allows multiple transactions to obtain read locks on the same page at the same time; The write lock only allows one transaction to obtain a write lock on a data page and modify the data in the working version; The commit lock is obtained by upgrading the write lock to the commit lock; If a data page has a read lock, the upgrade of the commit lock will be blocked; If the read lock request is blocked after the commit lock is upgraded, the commit lock will completely release the working space; In step 3, the database worker thread concurrently executes the transaction with the highest priority in step 2 by using the double-loop structure, and acquires and releases locks in the execution process by using a multi-version concurrency control strategy, specifically as follows: A new node is inserted into the node of the transaction queue, the transaction corresponding to the new node and the register state are the same as those of the blocked transaction, and the priority is inherited from the blocked transaction; when the shadow node releases the lock causing the blocking, the system deletes the shadow node from the transaction queue; Step 4: according to the execution of the transaction with the highest priority in step 3, the database worker thread commits or rolls back the transaction. Step 2 is specifically as follows:

2. The dynamic real-time transaction scheduling method of claim 1, wherein: The highest primary priority transaction is obtained by scanning the head node of the transaction queue after the inserted transaction, if the highest primary priority transaction is unique, the transaction is returned as the highest priority transaction; If not, all transactions with the same primary priority are scanned from the head one by one, a custom value function is used to compare the secondary priorities of the transactions with the same primary priority, and the transaction with the highest secondary priority is selected as the final highest priority transaction. ​ 3. The dynamic real-time transaction scheduling method of claim 1, wherein: In the step 4, the database worker thread commits the transaction, synchronizes the modification of the transaction in the working space to the consistent space, specifically: When the transaction is ready to commit, the write lock is upgraded to a commit lock; Before the commit, the conflict between the commit lock upgrade and the read lock of other transactions is checked; Once the commit lock upgrade is successful, the modification in the working space is written to the consistent space; After the commit is completed, the read lock, write lock and commit lock occupied by the transaction are released, and the working space of the transaction is cleaned to release system resources for subsequent transactions; The transaction production thread is sent a signal that the transaction commit is completed.

4. The dynamic real-time transaction scheduling method of claim 1, wherein: In the step 4, the database worker thread rolls back the transaction, reverts the modification of the transaction to the data during execution and releases the resources, specifically: The working space of the transaction is cleaned, and all modifications of the transaction to the data in the working space are reverted; After the working space is cleaned, the read lock and write lock held by the transaction are released; The transaction production thread is sent a signal that the transaction commit fails.

5. The dynamic real-time transaction scheduling method of claim 1, wherein: The transaction production thread and the database worker thread adopt a publish-subscribe model, the transaction production thread as a publisher puts the transaction request into the transaction queue, and the database worker thread as a consumer takes out and executes the transaction from the queue.

6. A dynamic real-time transaction scheduling system, characterized by: It includes: The transaction production module: the transaction production thread gives the transaction a priority and a deadline, and inserts the transaction into the transaction queue after converting it into a bytecode instruction set; The transaction management module: the transaction queue sorts the inserted transactions according to the priority for the first time, and sorts the transactions with the same priority according to the earliest deadline first for the second time, and selects the transaction with the highest priority; The transaction execution module: the database worker thread uses a double loop structure to execute the transaction with the highest priority concurrently; The double loop structure of the database worker thread includes an outer loop and an inner loop; The outer loop reads the transaction with the highest priority from the transaction queue, and the inner loop executes the bytecode instructions of the transaction according to the program counter of the transaction, and checks the pre-emptive scheduling flag in the transaction queue; When the pre-emptive scheduling flag is true, the pre-emptive scheduling is triggered, the inner loop ends, and the outer loop is re-entered to read the transaction with the highest priority, and the inner loop executes the bytecode instructions of the transaction; The pre-empted transaction saves its context information in the register group, and is temporarily suspended, waiting for re-scheduling and execution; When the database worker thread uses a double loop structure to execute the transaction with the highest priority concurrently, the multi-version concurrency control strategy is used to manage the acquisition and release of locks during execution, specifically: The database storage space is divided into a consistent version and a working version; The read lock request acts on the consistent version, and the write lock request acts on the working version; The read lock allows multiple transactions to obtain read locks on the same page simultaneously; The write lock only allows one transaction to obtain a write lock on a data page and modify the data in the working version; The commit lock is obtained by upgrading the write lock to the commit lock; If there is a read lock on a data page, the upgrade of the commit lock will be blocked; If the read lock request is blocked after the commit lock is upgraded, the commit lock will completely release the working space. When the database worker thread executes the highest priority transaction concurrently in a double loop structure, if transaction blocking occurs, priority inheritance is realized through the shadow node method, which is as follows: A new node is inserted into the node of the transaction queue, the transaction and register state of the new node are the same as those of the blocked transaction, and the priority is inherited from the blocked transaction; when the shadow node releases the lock that causes blocking, the system deletes the shadow node from the transaction queue; The transaction notification module: according to the execution of the highest priority transaction, the database worker thread commits or rolls back the transaction.

Images