Dynamic real-time transaction scheduling method and system

Abstract

The invention discloses a dynamic real-time transaction scheduling method and system, and the method breaks through the limitation of predefining transactions and periodic scheduling, enables the real-time transactions to be dynamically scheduled according to actual demands under the condition of not needing to predefine the transactions through two-time priority ranking, guarantees that the transactions are completed before the deadline, and improves the scheduling efficiency. Therefore, the flexibility and real-time guarantee of the system are obviously improved; on the basis that a database working thread adopts a dual loop structure, a multi-version concurrent access strategy and a shadow node strategy based on priority inheritance are introduced, so that a real-time database system can operate more efficiently under a complex transaction load, and the real-time response capability is further enhanced; priority distribution and blocking management are carried out on transactions by utilizing the characteristics of a real-time operating system, so that the real-time performance of the real-time operating system is not damaged in a transaction scheduling process, and the efficient response capability of the system is maintained; the invention also provides a system for realizing the method.

Description

Technical Field

[0001] The present invention relates to the technical field of real-time databases, and in particular to a dynamic real-time transaction scheduling method and system. Background Art

[0002] Traditional real-time database management systems (RTDBS) are widely used in embedded environments and usually rely on predefined transactions and periodic scheduling to meet real-time requirements. Such systems predefine transaction types, execution times, and priorities, and use periodic scheduling algorithms to ensure that transactions are completed on time. However, this approach shows obvious shortcomings under dynamic and changing system requirements, mainly reflected in insufficient flexibility and low resource utilization. In addition, the fixed nature of predefined transactions makes it difficult for the system to adapt to dynamically changing task requirements at runtime, further limiting the system's adaptability.

[0003] In terms of concurrency control and transaction scheduling, traditional real-time database management systems (RTDBS) mostly use locking mechanisms or time slicing methods. However, in high-concurrency and complex transaction scenarios, these methods are prone to lock contention, priority inversion and other problems, which affect the system's response speed and performance, and are difficult to meet the higher requirements for real-time and efficient concurrent processing. At the same time, the scheduling and execution of transactions rarely considers the real-time performance of the original real-time operating system (RTOS), which often destroys the real-time performance of the operating system, resulting in task scheduling conflicts and increased system delays. Therefore, there is an urgent need for a real-time database management method that can dynamically schedule transactions, optimize resource utilization, adapt to changing requirements, and does 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 device for processing real-time transactions. The method dynamically determines whether a data item is locked and whether a transaction needs 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 a system with a large number of concurrent transactions, the method optimizes lock allocation decisions and improves the overall performance of the system, and discloses a corresponding processing device; the scheme uses transaction restart to handle lock conflicts, which may cause the system to execute too many unnecessary transactions. In high-concurrency or complex scenarios, it is easy to cause frequent restarts, affecting the overall system performance and stability, that is, it cannot cope with high-concurrency scenarios.

[0005] The invention patent with publication number CN105243097A proposes a real-time transaction priority determination and concurrency control method for aerospace measurement and control database. The method allocates priority based on transaction value, and optimizes transaction execution in a high-concurrency environment through improved priority inheritance and deadlock processing algorithms, ensuring the priority of hard real-time transactions, improving the on-time completion rate of soft real-time transactions, and reducing the transaction abort rate; however, the scheme does not fully consider the real-time nature 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 problem of multiple priority inheritance, which may lead to excessive resource consumption in complex multi-inheritance scenarios and affect the overall performance of the system. Summary of the invention

[0006] In order to overcome the defects of the above-mentioned prior art, the purpose of the present invention is to provide a dynamic real-time transaction scheduling method and system, which breaks through the limitations of predefined transactions and periodic scheduling. Through two priority sorting, real-time transactions can be dynamically scheduled according to actual needs without predefined transactions, ensuring that transactions are completed before their deadlines, thereby significantly improving the flexibility and real-time guarantee of the system; at the same time, on the basis of the dual loop structure adopted by 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 run more efficiently under complex transaction loads and further enhance the real-time response capability; the characteristics of the real-time operating system are used to assign priorities and manage congestion for transactions, thereby ensuring that the real-time performance of the real-time operating system is not destroyed during the transaction scheduling process and maintaining the efficient response capability of the system.

[0007] In order to achieve the above object, the technical solution adopted by the present invention is:

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

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

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

[0011] Step 3: The database worker thread uses a double loop structure to concurrently execute the transaction with the highest priority in step 2;

[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, the step 2 is specifically as follows:

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

[0015] If it is not unique, all transactions with the same primary priority are scanned one by one starting from the head of the queue, and the secondary priorities of all transactions with the same primary priority are compared using a custom value function, and the transaction with the highest secondary priority is selected as the final highest priority transaction.

[0016] Furthermore, the customized value function is an Earliest Deadline First (EDF) scheduling method.

[0017] Furthermore, the step 3 is specifically as follows:

[0018] The double loop structure of the database working thread includes an outer loop and an inner loop;

[0019] The outer loop continuously reads the transaction with the highest current priority from the transaction queue, while the inner loop executes the bytecode instructions of the transaction according to the program counter of the transaction 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 group and temporarily suspend it, waiting to be rescheduled for execution.

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

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

[0024] Read lock requests act on the consistent version, and write lock requests act on the working version;

[0025] Read locks allow multiple transactions to obtain read locks on the same page at the same time;

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

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

[0028] If a data page already has a read lock, the commit lock upgrade will be blocked;

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

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

[0031] Insert a new node into the nodes of the transaction queue. The transaction and register status corresponding to 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 the blockage, the system deletes the shadow node from the transaction queue.

[0032] Furthermore, when the database worker thread commits the transaction in step 4, the modifications of the transaction in the workspace are synchronized to the consistency space, specifically:

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

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

[0035] Once the commit lock is upgraded successfully, the changes in the workspace are written to the consistency space;

[0036] After the commit is completed, the read lock, write lock, and commit lock occupied by the transaction are released, and the transaction workspace is cleaned up to release system resources for subsequent transactions;

[0037] Sends a semaphore to the transaction production thread indicating that the transaction commit is complete.

[0038] Furthermore, when the database working thread rolls back the transaction in step 4, the modifications made to the data during the execution of the transaction are undone and resources are released, specifically:

[0039] Clean up the workspace of the transaction and undo all modifications made by the transaction to the data in the workspace;

[0040] After the workspace is cleaned up, the read lock and write lock held by the transaction are released;

[0041] Sends a semaphore to the transaction production thread indicating that the transaction commit failed.

[0042] Furthermore, the transaction production thread and the database working thread adopt a publish-subscribe model, the transaction production thread as a publisher puts the transaction request into the transaction queue, and the database working thread as a consumer takes it out of the queue and executes the transaction.

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

[0044] Transaction production module: The transaction production thread assigns priority and deadline to transactions, converts transactions into bytecode instruction sets, and inserts them into the transaction queue;

[0045] Transaction management module: The transaction queue is sorted first according to the priority of the inserted transaction, and the transactions with the same priority are sorted secondly through a custom value function;

[0046] Transaction execution module: The database worker thread uses 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 present invention has the following beneficial effects:

[0049] 1. The practical queue of the present invention is sorted twice. 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 the transaction is consistent with the priority of the operating system task and to ensure the real-time performance of the operating system; the second sorting is dynamically calculated based on a custom value function, which can be dynamically adjusted according to the specific needs of the user, thereby giving the system higher flexibility; while maximizing the real-time performance of the operating system through two priority sortings, the system's scheduling flexibility and transaction execution efficiency are also improved through dynamic adjustment.

[0050] 2. The present invention continuously reads the current 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 give priority to executing newly arrived high-priority transactions, ensuring real-time requirements to the greatest extent.

[0051] 3. The database working thread of the present invention adopts a multi-version concurrent access strategy, supports read-write separation, and greatly reduces resource consumption during transaction submission and rollback, thereby improving the concurrent processing capability of transactions.

[0052] 4. The present invention implements the priority inheritance strategy in the form of shadow nodes, which not only effectively reduces the resource consumption caused by thread switching, but also supports multiple inheritance, greatly improving the blocking processing capability of the real-time database management system in complex transaction scenarios.

[0053] 5. The present invention adopts a publish-subscribe model. The transaction production thread acts as a publisher to put the transaction request into the transaction queue. The database working thread acts as a consumer to take out the transaction from the queue and execute the transaction. This can uniformly manage all database transaction requests, making operation scheduling more flexible. The blocking between transactions only requires saving the status and suspending it, without actually switching threads, which greatly simplifies the scheduling logic.

[0054] In summary, the real-time transaction scheduling method of the present invention breaks through the limitations of predefined transactions and periodic scheduling. Through two priority sorting, real-time transactions can be dynamically scheduled according to actual needs without predefined transactions, ensuring that transactions are completed before their deadlines, thereby significantly improving the flexibility and real-time guarantee of the system; at the same time, on the basis of the dual loop structure adopted by 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 run more efficiently under complex transaction loads and further enhance the real-time response capability; the characteristics of the real-time operating system are used to assign priorities and manage congestion for transactions, thereby ensuring that the real-time performance of the real-time operating system is not destroyed during the transaction scheduling process and maintaining the efficient response capability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0055] Figure 1 The flowchart of the dynamic real-time transaction scheduling method of the present invention is shown in FIG.

[0056] Figure 2 It is a double loop structure diagram of the database working thread of the present invention.

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

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

[0059] Figure 5 It is a schematic diagram of the consistency space and workspace in the multi-version concurrent access control of the present invention.

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

[0061] Figure 7 Request SQLite response time for different priority tasks on RT-Thread platform.

[0062] Figure 8 A time-box diagram of SQLite response requests for different priority tasks on the RT-Thread platform.

[0063] Fig. 9The invention provides the response time of the real-time transaction scheduling system constructed based on the method of the present invention for different priority task requests under the RT-Thread platform.

[0064] Fig.10 The present invention is a time-box diagram of the response of a real-time transaction scheduling system constructed based on the method of the present invention to different priority task requests on an RT-Thread platform. DETAILED DESCRIPTION

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

[0066] See also Figure 1 , a dynamic real-time transaction scheduling method, comprising the following steps:

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

[0068] When assigning transaction priority, the system will assign a priority to the transaction, and the deadline is assigned according to the user's needs to constrain the completion time of the transaction. The bytecode instruction set of the transaction contains the sequence of operations that need to be performed by the transaction, which is dynamically generated by the transaction production thread according to the transaction requirements;

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

[0070] When converting a transaction into a bytecode instruction set and inserting it into the transaction queue, since the transaction request is designed to be synchronous, it will enter a blocking state, which is used to wait and listen to the semaphore of the database worker thread to complete the transaction. Once the transaction is completed or aborted, the transaction production thread will be notified through the semaphore issued by the subsequent database worker thread, and will be responsible for cleaning up the transaction resources and 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 transaction inserted in step 1, and the transactions with the same priority are sorted for the second time through the 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, which is responsible for storing all transactions to be executed and dynamically maintaining the priority order of transactions in the queue.

[0073] Furthermore, the step 2 is specifically as follows:

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

[0075] If it is not unique, all transactions with the same primary priority are scanned one by one starting from the head of the queue, and the secondary priorities of all transactions with the same primary priority are compared using a custom value function, and the transaction with the highest secondary priority is selected as the final highest priority transaction.

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

[0077] The second sorting is dynamically calculated based on a custom value function, which can be dynamically adjusted according to the specific needs of the user, giving the system greater flexibility. For example, the priority 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 perform dynamic priority sorting on transactions with the same primary priority and optimize transaction scheduling efficiency.

[0078] The above two-tier priority mechanism not only ensures the real-time performance of the operating system to the maximum extent, but also improves the system's scheduling flexibility and transaction execution efficiency through dynamic adjustment.

[0079] Furthermore, the customized value function is an Earliest Deadline First (EDF) scheduling method.

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

[0081] Step 3: The database worker thread uses a double loop structure to concurrently execute the transaction with the highest priority in step 2;

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

[0083] Furthermore, the step 3 is specifically as follows:

[0084] The double loop structure of the database working thread includes an outer loop and an inner loop;

[0085] The outer loop continuously reads the transaction with the highest current priority from the transaction queue, while the inner loop executes the bytecode instructions of the transaction according to the program counter of the transaction 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 group and temporarily suspend it, waiting to be rescheduled for execution.

[0088] This embodiment uses a dual loop structure to continuously read the current highest priority transaction from the transaction queue, ensuring that the entire system can respond to changes in the transaction queue in real time; at the same time, through the preemptive scheduling mechanism, the system can give priority to executing newly arrived high-priority transactions, ensuring real-time requirements to the greatest extent.

[0089] like Figure 2 It is a double loop structure of this embodiment. The outer layer is an infinite loop, which continuously reads the transaction with the highest priority from the transaction queue; the inner layer is a bytecode execution loop. When the transaction switch flag State is false, the database worker thread determines the atomic operation to be executed next through switch according to the bytecode instruction pointed to by the program counter in the transaction structure. After each instruction is executed, the program counter increments and points to the next bytecode instruction to be executed. If the transaction switch flag State is true, preemptive scheduling is triggered, and the transaction with the highest priority is read and processed again from the transaction queue.

[0090] like Figure 3 As a preemptive scheduling case of this embodiment, when the database worker thread DBW orkThread is executing transaction T2 initiated by the second transaction production thread WorkThread2 with a priority of 2, the first transaction production 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 starts to execute; in order to ensure that transaction T1 is given priority, 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 uses a double loop structure to concurrently execute the transaction with the highest priority in step 2, a multi-version concurrent access strategy is used to manage the acquisition and release of locks during the execution process, specifically:

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

[0093] Read lock requests act on the consistent version, and write lock requests act on the working version;

[0094] Read locks allow multiple transactions to obtain read locks on the same page at the same time;

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

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

[0097] If a data page already has a read lock, the commit lock upgrade will be blocked;

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

[0099] The acquisition and release of locks during the execution process are managed through the above-mentioned multi-version concurrent access strategy, which supports read-write separation and greatly reduces the resource consumption of transactions during subsequent submission and rollback processes, thereby improving the concurrent processing capabilities of transactions.

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

[0101] Insert a new node into the nodes of the transaction queue. The transaction and register status corresponding to 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 the blockage, the system deletes the shadow node from the transaction queue.

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

[0103] like Figure 4A case study of implementing a priority inheritance strategy for shadow nodes. In the current transaction queue, transactions T2, T3, and T4 are arranged in descending order according to 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, the present invention adopts a shadow node mechanism to insert a new shadow node after transaction T2, and the transaction pointer of the node points to T4; when transaction T4 releases resources, the shadow node is deleted, and there is no need to perform the complex operation of deleting and reinserting transaction T4 twice; this can simplify the management of the transaction queue and ensure 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, when the database worker thread commits the transaction in step 4, the modifications of the transaction in the workspace are synchronized to the consistency space, specifically:

[0106] When a transaction is ready to be committed, the write lock is upgraded to a commit lock. During the commit lock 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, check for conflicts with read locks of other transactions during commit lock escalation. If other transactions hold read locks on the same data object, commit lock escalation will be blocked and the commit operation will continue after the read lock is released.

[0108] Once the commit lock is successfully upgraded, 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 partial changes from being written and causing incomplete data.

[0109] After the commit is completed, the read lock, write lock, and commit lock occupied by the transaction are released, and the transaction workspace is cleaned up to release system resources for subsequent transactions;

[0110] Send a transaction submission completion signal to the transaction production thread to notify it that the transaction has been successfully submitted; the transaction production thread determines that the transaction has been successfully executed based on the monitored transaction submission completion signal;

[0111] Furthermore, when the database working thread rolls back the transaction in step 4, the modifications made to the data during the execution of the transaction are undone and resources are released, specifically:

[0112] Clean up the workspace of the transaction and undo all modifications made by the transaction to the data in the workspace;

[0113] After the workspace is cleaned up, the read lock and write lock held by the transaction are released;

[0114] A semaphore indicating that the transaction submission has failed is sent to the transaction production thread, and the transaction production thread determines that the transaction execution has failed based on the semaphore indicating that the transaction submission has been monitored.

[0115] like Figure 5 As shown, the relationship between the consistency space and the workspace of this embodiment is clearly demonstrated; the consistency space is the storage area for the full amount of data in the real-time database, providing a global consistency view of the system data; and the workspace is used to store the copy of the modified data object during the transaction execution, and is maintained separately for each transaction to ensure the isolation of the transaction and the protection of the original data; each page in the consistency space can only have one copy page in the workspace, that is, if you want to generate a copy page of a page in the consistency space, you need to get the write lock of this page first. During the transaction execution process, access to data objects needs to follow the corresponding lock mechanism; before reading or writing data objects, transactions must first obtain the corresponding read lock or write lock; read operations on data objects are read directly from the consistency space to ensure that the latest globally consistent data is read; and write operations on data objects will update the value of the data object in the workspace, and will not directly affect the data in the consistency space until the transaction is committed. The changes in the workspace are merged into the consistency space; this design ensures the concurrent execution capability of transactions while maintaining the consistency and isolation of data.

[0116] Furthermore, the transaction production thread and the database working thread adopt a publish-subscribe model, the transaction production thread as a publisher puts the transaction request into the transaction queue, and the database working thread as a consumer takes it out of the queue and executes the transaction.

[0117] In real-time database transaction management, transactions can be executed in two modes: publish-subscribe model and local execution model. A significant advantage of the publish-subscribe model over the local execution model is that it can manage all database transaction requests in a unified manner, 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, without actually switching threads, which greatly simplifies the scheduling logic. In addition, lock management is completed by a single thread, making the lock design more flexible and management more convenient.

[0118] like Figure 6The publish-subscribe model of the embodiment is used in the entire real-time transaction scheduling framework to manage the execution and scheduling of real-time transactions. The design of this model fully considers the dynamics of the real-time system and the efficiency of task scheduling. In this model, the transaction production thread WorkThread acts as a publisher and puts transaction requests into the transaction queue. These transaction requests include the priority, deadline and other key execution parameters of the transaction. At the same time, the database work thread acts as a consumer, continuously subscribes to the real-time transactions in the transaction queue, and processes the transactions in descending order of priority. Through the collaborative work of the transaction production thread, the transaction queue and the database work 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, converts transactions into bytecode instruction sets, and inserts them into the transaction queue;

[0121] Transaction management module: The transaction queue is sorted first according to the priority of the inserted transaction, and the transactions with the same priority are sorted secondly through a custom value function;

[0122] Transaction execution module: The database worker thread uses 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 effect of the present invention is 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 usually use sequential or lock contention scheduling when processing transactions, while the real-time transaction scheduling system built based on the method of the present invention introduces a priority scheduling mechanism to optimize the execution order of transactions and ensure timely response of key tasks.

[0126] This test is based on the RT-Thread platform, simulating high, medium and low priority tasks, and measuring the response time of transactions of different priorities to evaluate the scheduling performance of the database in a multi-tasking environment. In order to comprehensively analyze the scheduling characteristics of the database, the test is carried out on SQLite and the real-time transaction scheduling system built based on the method of the present invention to observe 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 the present invention.

[0127] In order to evaluate the response time of SQLite and the real-time transaction scheduling system built based on the method of the present invention in processing 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 respectively. The response time of the corresponding transaction was recorded for each batch, and the performance of transactions of different priorities in a multi-task concurrent environment was displayed through a scatter plot.

[0128] like Figure 7 The results of SQLite response time requests for different priority tasks on the RT-Thread platform are as follows:

[0129] When executing three priority tasks concurrently, SQLite uses a mutual exclusion mechanism for transactions containing write operations. Therefore, no matter which priority task obtains the execution right of SQLite first, the SQLite requests of the other two tasks will be blocked. After the current task is executed, RT-Thread will wake up the relatively high priority task to request SQLite. Therefore, the execution order of concurrent tasks may be high-medium-low, medium-high-low, or low-high-medium.

[0130] exist Figure 7 In the figure, you can see three response time bands. The fast response time band includes high, medium, and low transactions. That is, among concurrent requests, whoever obtains the execution right of SQLite first will have a response time within this time band. Since high-priority transactions have a higher priority, their response time will only appear in the fast response time band and the medium response time band. Low-priority transactions have a lower priority, and their response time will only appear in the fast response time band and the slow response time band, while medium-priority transactions will appear in all three time bands. In order to more intuitively display the response time distribution of the three priority transactions, the following is drawn: Figure 8 The box plot is shown as follows:

[0131] The length of the box in the box diagram represents the concentration range of data to a certain extent. In the test case of SQLite, the length of the low and medium priority boxes spans across three response time bands, that is, the response time fluctuates greatly. Since high priority transactions are initiated by high priority tasks in RTthread and have priority scheduling rights, the length of the box is relatively short and only concentrated in the medium and low response time bands. It can be seen that SQLite's real-time response capability in the real-time operating system is average, and the response time fluctuates greatly.

[0132] from Fig. 9It can be seen that the response time of the real-time transaction scheduling system constructed based on the method of the present invention is also concentrated in three time bands, but different from the response time distribution of SQLite, the response time of each priority task shows a more clear stratification phenomenon. Among them, the response time of the high priority task only appears in the fast response time band, the response time of the medium priority task only appears in the medium speed response time band, and the response time of the low priority task completely falls in the low speed response time band.

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

[0134] In order to further quantify the transaction scheduling stability of SQLite and the real-time transaction scheduling system built based on the method of the present invention on the RT-Thread platform, the response time variance of three priority transactions was calculated. The larger the variance, the greater the fluctuation of the transaction response time and the more unstable the real-time performance; the smaller the variance, the more concentrated the transaction execution time and the more deterministic the scheduling mechanism. As shown in Table 1 below, the response time variance of SQLite and the real-time transaction scheduling system built based on the method of the present invention under high, medium and low priority transactions is listed:

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

[0136]

[0137] As can be seen from Table 1, the variance of the response time of SQLite under different priority transactions is much higher than that of the real-time transaction scheduling system constructed based on the method of the present invention, especially the variance of low-priority transactions is as high as 358340.5, indicating that its response time fluctuates greatly and is more obviously affected by lock competition and scheduling strategies. In contrast, the variance of the real-time transaction scheduling system constructed based on the method of the present invention is significantly reduced, and the variance of low-priority transactions is only 97.08, indicating that its execution time is more stable and not easily disturbed by high-priority transactions. In addition, the variance of the high-priority transaction of SQLite is 94872.19, while the real-time transaction scheduling system constructed based on the method of the present invention is only 521.76, indicating that the scheduling mechanism of the real-time transaction scheduling system constructed based on the method of the present invention can better ensure the execution stability of high-priority transactions and reduce the uncertainty of response time.

[0138] This feature shows that the real-time transaction scheduling system constructed based on the method of the present invention can be strictly scheduled according to the task priority under the RT-Thread platform, and high-priority tasks can obtain execution rights and complete transactions more quickly, while medium and low-priority tasks are completed in a longer time frame. This phenomenon of strict priority division is in sharp contrast to the randomness and volatility of SQLite when processing transactions, verifying the deterministic and real-time advantages of the real-time transaction scheduling system constructed based on the method of the present 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 of the present invention and the protection scope of the claims are within the protection scope of the present invention.

Claims

1. A dynamic real-time transaction scheduling method, characterized in that: The following steps are involved: Step 1: The transaction production thread assigns priority and deadline to the transaction, converts the transaction into a bytecode instruction set, and inserts it into the transaction queue; Step 2: The transaction queue is sorted for the first time according to the priority of the transaction inserted in step 1, and the transactions with the same priority are sorted for the second time through the custom value function to select the transaction with the highest priority; Step 3: The database worker thread uses a double loop structure to concurrently execute the transaction with the highest priority in step 2; 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.

2. A dynamic real-time transaction scheduling method according to claim 1, characterized in that: The step 2 is specifically as follows: The transaction with the highest primary priority is obtained by scanning the head node of the transaction queue after the transaction is inserted. If the transaction with the highest primary priority is unique, the transaction is returned as the transaction with the highest priority. If it is not unique, all transactions with the same primary priority are scanned one by one starting from the head of the queue, and the secondary priorities of all transactions with the same primary priority are compared using a custom value function, and the transaction with the highest secondary priority is selected as the final highest priority transaction.

3. A dynamic real-time transaction scheduling method according to claim 2, characterized in that: The customized value function is the Earliest Deadline First (EDF) scheduling method.

4. A dynamic real-time transaction scheduling method according to claim 1, characterized in that: The step 3 is specifically as follows: The double loop structure of the database working thread includes an outer loop and an inner loop; The outer loop continuously reads the transaction with the highest current priority from the transaction queue, while the inner loop executes the bytecode instructions of the transaction according to the program counter of the transaction and checks the preemptive scheduling flag in the transaction queue; 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; The preempted transaction will save its context information in the register group and temporarily suspend it, waiting to be rescheduled for execution.

5. A dynamic real-time transaction scheduling method according to claim 1, characterized in that: In step 3, when the database worker thread uses a double loop structure to concurrently execute the transaction with the highest priority in step 2, a multi-version concurrent access strategy is used to manage the acquisition and release of locks during the execution process, specifically: Divide the database storage space into consistent versions and working versions; Read lock requests act on the consistent version, and write lock requests act on the working version; Read locks allow multiple transactions to obtain read locks on the same page at the same time; A 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 acquired by upgrading the write lock to a commit lock; If a data page already has a read lock, the commit lock upgrade will be blocked; If the commit lock request is upgraded, the read lock request for the memory page will be blocked until the commit lock completely releases the workspace.

6. A dynamic real-time transaction scheduling method according to claim 1, characterized in that: In step 3, when the database worker thread uses a double loop structure to concurrently execute the transaction with the highest priority in step 2, if transaction blocking occurs, priority inheritance is implemented through the shadow node method, specifically: Insert a new node into the nodes of the transaction queue. The transaction and register status corresponding to 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 the blockage, the system deletes the shadow node from the transaction queue.

7. A dynamic real-time transaction scheduling method according to claim 1, characterized in that: When the database working thread commits the transaction in step 4, the modifications of the transaction in the workspace are synchronized to the consistency space, specifically: When the transaction is ready to be committed, the write lock is upgraded to a commit lock; Before committing, check for conflicts with read locks of other transactions during the commit lock upgrade process; Once the commit lock is upgraded successfully, the changes in the workspace are written to the consistency space; After the commit is completed, the read lock, write lock, and commit lock occupied by the transaction are released, and the transaction workspace is cleaned up to release system resources for subsequent transactions; Sends a semaphore to the transaction production thread indicating that the transaction commit is complete.

8. A dynamic real-time transaction scheduling method according to claim 1, characterized in that: When the database worker thread rolls back the transaction in step 4, the modifications made to the data during the execution of the transaction are undone and resources are released, specifically: Clean up the workspace of the transaction and undo all modifications made by the transaction to the data in the workspace; After the workspace is cleaned up, the read lock and write lock held by the transaction are released; Sends a semaphore to the transaction production thread indicating that the transaction commit failed.

9. A dynamic real-time transaction scheduling method according to claim 1, characterized in that: The transaction production thread and the database working thread adopt a publish-subscribe model. The transaction production thread, as a publisher, puts the transaction request into the transaction queue, and the database working thread, as a consumer, takes it out of the queue and executes the transaction.

10. A dynamic real-time transaction scheduling system, characterized in that: include: Transaction production module: The transaction production thread assigns priority and deadline to transactions, converts transactions into bytecode instruction sets, and inserts them into the transaction queue; Transaction management module: The transaction queue is sorted first according to the priority of the inserted transaction, and the transactions with the same priority are sorted secondly through a custom value function; Transaction execution module: The database worker thread uses a double loop structure to concurrently execute the highest priority transaction; Transaction notification module: Based on the execution status of the highest priority transaction, the database worker thread commits or rolls back the transaction.

Images