Multi-transaction deadlock detection and processing method in resource-constrained equipment

Abstract

The invention provides a multi-transaction deadlock detection and processing method in resource-constrained equipment, which comprises the following steps of: in a transaction execution process, constructing a resource waiting graph which is used for recording a waiting relationship among transactions so as to reflect the occupation condition of shared resources by the transactions and a dependency relationship among the transactions; before a transaction is subjected to read-write operation each time, whether execution of the current transaction can cause a deadlock risk or not is judged in real time by detecting a dependency relationship between the current transaction and a target resource and combining a resource waiting graph; and when a deadlock risk is detected, deadlock avoidance strategies of priority processing, transaction rollback, transaction retry and exception processing are adopted to avoid deadlock. The deadlock problem occurring in the transaction parallel processing process can be effectively avoided or solved, and meanwhile the response efficiency of the application and the utilization rate of the storage space are guaranteed.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and particularly relates to a method for detecting and handling multi-transaction deadlocks in resource-constrained devices. Background Art

[0002] In resource-constrained devices, such as smart cards, embedded systems, etc., FLASH storage is usually used as the only persistent storage medium. Virtual machines on these devices need to support the installation and operation of multiple applications. Due to extremely limited resources, multiple applications often share the same storage device. And to maximize the utilization rate of storage space, the heap data between applications is not fully isolated, but a storage allocation strategy of first-come, first-served is adopted.

[0003] With the complication of application scenarios and the growth of business requirements, traditional single-threaded virtual machines can no longer meet the needs of efficient concurrent processing. Therefore, multi-virtual thread virtual machines have emerged. It supports the concurrent operation of multiple applications and can achieve the parallel processing of multiple transactions. As an atomic operation, a transaction requires that either all data is successfully updated or all remains unchanged during its execution, that is, it has the characteristic of "all or nothing". To ensure the atomicity of transactions, a transaction rollback mechanism is introduced, and transaction backup is a key link.

[0004] Currently, transaction backup mechanisms are mainly divided into two ways: page-based backup and record-based backup. Page-based backup performs data backup in units of storage pages, while record-based backup backs up each data record. However, when implementing these two backup methods in resource-constrained devices, potential deadlock problems are faced.

[0005] Deadlock refers to a situation where two or more transactions are unable to continue execution during the execution process because they are waiting for resources held by each other. In a database server environment with rich resources, this problem is usually solved through a deadlock detection mechanism. These mechanisms either wait for a period of time for detection after a deadlock occurs, or periodically perform global transaction deadlock detection on the database system. However, these methods are not applicable in resource-constrained devices.

[0006] First, the performance, storage, and computing capabilities of resource-constrained devices are extremely limited and cannot support complex deadlock detection mechanisms. Second, the applications on these devices have extremely high requirements for response efficiency, and timed deadlock detection will seriously affect the execution efficiency of applications. Therefore, traditional database transaction deadlock detection and prevention mechanisms are difficult to effectively apply in resource-constrained devices.

[0007] In summary, there is a lack of a transaction processing mechanism for multi-virtual thread virtual machines applicable to resource-constrained devices in the prior art, which is used to solve the deadlock problem encountered when implementing multi-transaction parallel processing in such an environment. Summary of the Invention

[0008] In view of the deficiencies of the prior art, the present invention provides a method for multi-transaction deadlock detection and handling in resource-constrained devices, which can effectively avoid or solve the deadlock problems that occur during the parallel processing of transactions, while ensuring the response efficiency of the application and the utilization rate of the storage space.

[0009] The present invention achieves the above object through the following technical solutions:

[0010] A method for multi-transaction deadlock detection and handling in resource-constrained devices, comprising the following steps:

[0011] During the execution of a transaction, construct a resource waiting graph, which is used to record the waiting relationships between transactions to reflect the occupancy of shared resources by each transaction and the dependencies between them;

[0012] Before each read / write operation of a transaction, by detecting the dependency relationship between the current transaction and the target resource, and combining with the resource waiting graph, determine in real time whether the execution of the current transaction will cause the occurrence of a deadlock risk;

[0013] When a deadlock risk is detected, adopt a deadlock avoidance strategy of priority processing, transaction rollback, transaction retry, and exception handling to avoid the occurrence of a deadlock.

[0014] According to the method for multi-transaction deadlock detection and handling in resource-constrained devices provided by the present invention, the comprehensive strategy specifically includes: selecting a transaction with a lower priority for rollback according to the priorities of each transaction, releasing the resources it occupies to break the deadlock dependency loop; if the retry count of the rolled-back transaction does not reach the preset upper limit, allow the transaction to re-attempt execution after rollback; if the retry count of the rolled-back transaction reaches the preset upper limit, throw an exception and end the transaction.

[0015] According to the method for multi-transaction deadlock detection and handling in resource-constrained devices provided by the present invention, before a transaction performs a read / write operation, first determine the number of transactions opened in the current virtual machine, and record it through a global counter transaction_count;

[0016] Whenever a new transaction is opened, increment the value of the global counter transaction_count by 1;

[0017] Whenever a transaction ends, decrement the value of the global counter transaction_count by 1;

[0018] Before determining whether there is a deadlock risk, first check the value of the global counter transaction_count. If transaction_count <= 1, it indicates that there is only the current transaction A executing in the virtual machine. At this time, it is determined that no deadlock will occur, and transaction A is directly allowed to perform read and write operations;

[0019] Moreover, in each write operation before the end of transaction A, the data of the write operation is backed up, and a resource list occupied by transaction A is maintained to facilitate resource recovery and deadlock handling when needed.

[0020] According to a multi-transaction deadlock detection and handling method in a resource-constrained device provided by the present invention, when the value of the global counter transaction_count is greater than 1, it indicates that two or more transactions are running in the virtual machine. At this time, there is a risk of deadlock, and further detection is required;

[0021] According to the target address and read / write length of transaction A, a target resource list that transaction A is about to read and write is statistically calculated. The target resource list includes consecutive page numbers;

[0022] The obtained target resource list of transaction A is detected. By checking the resource lists occupied by all running transactions, it is determined whether the target resources that transaction A is about to read and write are not occupied by other transactions;

[0023] If the target resources that transaction A is about to read and write are not occupied by other transactions, transaction A is directly allowed to perform read and write operations;

[0024] If one or more of the target resources that transaction A is about to read and write are occupied by other transactions, the transaction ID corresponding to the first occupied resource is returned, denoted as transaction B, and resource detection is performed on transaction B to determine whether there is a deadlock risk, and corresponding deadlock avoidance strategies are adopted according to the detection results.

[0025] According to a multi-transaction deadlock detection and handling method in a resource-constrained device provided by the present invention, the following pre-detection steps are further included:

[0026] When it is determined that one or more of the target resources that transaction A is about to read and write are occupied by other transactions, starting from the transaction B that occupies the resources, the resource waiting graph is traversed to find whether there is a node of the current transaction A in the resource waiting graph;

[0027] Among them, since the transaction is started in a virtual thread and each transaction can only be blocked by one transaction, the relevant resource waiting relationships are stored in the virtual thread control block;

[0028] During the traversal process, if a node of transaction A is found, it indicates that there is a dependency relationship between transaction A and transaction B, and this dependency relationship may form a loop, that is, there is a deadlock risk. At this time, handle it according to the deadlock avoidance strategy to avoid the occurrence of deadlocks.

[0029] If the node of transaction A is not found, it means that the dependency relationship between transaction A and transaction B will not form a loop. At this time, build a dependency relationship in the virtual thread control block, record the ID of transaction B in the waiting transaction ID field waiting for transaction A, and set the virtual thread where transaction A is located to the blocked state, and wait for transaction B to release the resource before waking up transaction A to continue execution.

[0030] According to a multi-transaction deadlock detection and handling method in a resource-constrained device provided by the present invention, define the structure of the virtual thread control block, including:

[0031] Transaction ID field: used to mark the transaction ID in the current virtual thread when starting a transaction;

[0032] Waiting transaction ID field: used to store the ID of other transactions occupying the resource when checking shared resources;

[0033] During the transaction startup process, assign a unique transaction ID to each transaction and mark it in the transaction ID field of its corresponding virtual thread control block;

[0034] During the shared resource check process, if it is found that the target resource is occupied by other transactions, store the transaction ID of the transaction occupying the resource in the waiting transaction ID field of the virtual thread control block corresponding to the transaction requesting the resource;

[0035] Based on the information in the transaction ID and waiting transaction ID fields, combined with the resource request and occupation relationship between transactions, dynamically construct a resource waiting graph to represent the waiting and dependency relationships between transactions for deadlock detection and avoidance.

[0036] According to a multi-transaction deadlock detection and handling method in a resource-constrained device provided by the present invention, during the process of constructing or updating the resource waiting graph, check whether the resource waiting graph contains the node of the current transaction A:

[0037] If the resource waiting graph does not contain the node of transaction A, it means that the dependency relationship formed between transaction A and transaction B occupying its required resource will not form a loop;

[0038] In this case, build a dependency relationship in the virtual thread control block corresponding to transaction A and record the ID of transaction B in the waiting transaction ID field;

[0039] Place the virtual thread where transaction A is located in a blocked state and wait for transaction B to release resources and then wake up transaction A to continue execution.

[0040] According to a multi-transaction deadlock detection and handling method in a resource-constrained device provided by the present invention, if the resource waiting graph already contains a node of transaction A, it indicates that the dependency relationship formed between transaction A and transaction B that occupies the resources it needs will form a loop, that is, there is a deadlock risk.

[0041] Then adopt the deadlock avoidance strategy to avoid the occurrence of deadlocks.

[0042] According to a multi-transaction deadlock detection and handling method in a resource-constrained device provided by the present invention, when it is detected that there is a loop in the resource waiting graph, that is, there is a deadlock risk, the deadlock avoidance strategy is adopted to avoid deadlocks.

[0043] Find a transaction with a lower priority in the loop for rollback processing, where the smaller the priority value, the higher the priority.

[0044] If the transaction with a lower priority found is transaction C, then perform the following steps:

[0045] Roll back transaction C to make the program state return to the state before transaction C was executed.

[0046] Reconstruct the waiting relationship between transaction A and transaction B for subsequent resource competition and transaction execution.

[0047] According to a multi-transaction deadlock detection and handling method in a resource-constrained device provided by the present invention, if the transaction with a lower priority found in the loop is still transaction A, then perform the following processing:

[0048] Check whether the number of retry times in transaction A has reached the upper limit, and the default upper limit of the number of retry times is 5 times.

[0049] When the retry counter is greater than or equal to 5 times, it means that transaction A has no chance to retry. At this time, throw a transaction exception to the application program to end the execution of transaction A.

[0050] If the number of retry times has not reached the upper limit, then perform the following sub-steps:

[0051] Roll back transaction A, release all resources occupied by transaction A, and notify other transactions waiting for transaction A to re-compete for resources to run.

[0052] The program state returns to the position where transaction A just started to execute so that transaction A can retry execution.

[0053] The retry count of transaction A is incremented to record the number of times transaction A has tried to execute.

[0054] Yield the execution right to allow other transactions to continue execution, ensuring the effective utilization of system resources and the sequential progress of transactions.

[0055] The present invention proposes an innovative transaction processing solution, especially for the multi-virtual thread virtual machine environment in resource-constrained devices. By constructing a resource waiting graph and combining appropriate deadlock resolution strategies, the deadlock problem between transactions is effectively avoided. The following are the beneficial effects of the present invention:

[0056] 1. Effectively avoid deadlocks: By constructing a resource waiting graph in real time, the present invention can dynamically monitor the resource dependency relationships between transactions and timely detect potential deadlock risks. Combining strategies such as transaction rollback, resource release, and transaction priority, the present invention can take preventive measures before deadlocks occur, ensuring the smooth execution of transactions and effectively avoiding system deadlocks caused by deadlocks.

[0057] 2. Improve system stability: Through a reasonably designed transaction processing mechanism, the present invention ensures the stable execution of multiple concurrent transactions in resource-constrained devices. During the execution of transactions, the present invention can dynamically adjust the execution order of transactions, giving priority to high-priority transactions, thereby improving the overall stability of the system.

[0058] 3. Maintain data consistency: The transaction processing solution of the present invention strictly follows the atomicity, consistency, isolation, and durability (ACID) principles, ensuring the consistency and integrity of data during the execution of transactions. Through the transaction rollback mechanism, the present invention can restore to the state before the transaction started when the transaction execution fails, ensuring that the data consistency is not affected.

[0059] 4. Adapt to resource-constrained devices: The present invention particularly considers the application scenarios and operating environment requirements of resource-constrained devices and designs a transaction processing mechanism suitable for devices with low memory and low computing power. By local resource detection and real-time deadlock prevention, the present invention reduces resource consumption and computational complexity, enabling efficient and stable execution of transactions in resource-constrained devices.

[0060] 5. Improve application performance and reliability: Combined with a virtual thread scheduler, the present invention can reasonably roll back the program and yield the execution right, enabling low-priority transactions to release resources first and high-priority transactions to execute first, thereby improving the response speed and execution efficiency of the application. By optimizing the transaction processing flow and reducing the deadlock risk, the present invention greatly improves the application performance and reliability in resource-constrained devices, providing a strong guarantee for the stable operation of the device.

[0061] In summary, the beneficial effects of the present invention are as follows: effectively avoiding the deadlock problem between transactions in resource-constrained devices, enhancing the stability and data consistency of the system, adapting to the application scenarios and operating environment requirements of resource-constrained devices, improving the application performance and reliability, providing an efficient and stable transaction processing mechanism for the multi-virtual thread virtual machine environment in resource-constrained devices, and having broad application prospects and practical value.

[0062] The present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] Figure 1 FIG. is a flowchart of an embodiment of a method for detecting and handling multi-transaction deadlocks in a resource-constrained device according to the present invention.

[0064] Figure 2 FIG. is an example diagram of the storage of application data in an embodiment of a method for detecting and handling multi-transaction deadlocks in a resource-constrained device according to the present invention.

[0065] Figure 3 FIG. is a schematic flowchart of deadlock detection and handling in an embodiment of a method for detecting and handling multi-transaction deadlocks in a resource-constrained device according to the present invention.

[0066] Figure 4 FIG. is a schematic structural diagram of a virtual thread control block in an embodiment of a method for detecting and handling multi-transaction deadlocks in a resource-constrained device according to the present invention.

[0067] Figure 5 FIG. is a schematic diagram of a resource waiting graph in an embodiment of a method for detecting and handling multi-transaction deadlocks in a resource-constrained device according to the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0068] To make the objectives, technical solutions, and advantages of the present invention clearer, the technical solutions in the present invention will be clearly and completely described below with reference to the accompanying drawings in the present invention. Obviously, the described embodiments are some, but not all, of the embodiments of the present invention. All other embodiments obtained by those of ordinary skill in the art without making creative efforts based on the embodiments in the present invention fall within the protection scope of the present invention.

[0069] Reference to "embodiment" in this document means that a particular feature, structure, or characteristic described in connection with the embodiment can be included in at least one embodiment of the present application. The phrase appears in various places in the specification and does not necessarily refer to the same embodiment, nor is it an independent or alternative embodiment mutually exclusive with other embodiments. Those skilled in the art will explicitly and implicitly understand that the embodiments described herein can be combined with other embodiments.

[0070] See Figures 1 to 5 This embodiment provides a method for multi-transaction deadlock detection and handling in resource-constrained devices, and the method includes the following steps:

[0071] Step S1, during the execution of a transaction, construct a resource waiting graph, which is used to record the waiting relationships between transactions to reflect the occupation of shared resources by each transaction and the dependencies between them;

[0072] Step S2, before each read / write operation of a transaction, by detecting the dependency between the current transaction and the target resource and combining with the resource waiting graph, determine in real time whether the execution of the current transaction will cause the occurrence of a deadlock risk;

[0073] Step S3, when a deadlock risk is detected, adopt deadlock avoidance strategies such as priority processing, transaction rollback, transaction retry, and exception handling to avoid the occurrence of deadlocks.

[0074] Among them, the comprehensive strategy specifically includes: select a transaction with a lower priority for rollback according to the priorities of each transaction, release the resources it occupies to break the deadlock dependency ring; if the retry count of the rolled-back transaction does not reach the preset upper limit, allow the transaction to retry execution after rollback; if the retry count of the rolled-back transaction reaches the preset upper limit, throw an exception and end the transaction, so as to ensure that other transactions can continue to execute and improve the efficiency and reliability of the SIM card self-service card writing process.

[0075] In this embodiment, as Figure 2 shown, the virtual machine contains three applications, and their installation order is APP1, APP2, and APP3. The FLASH space occupied during installation is in order, and the space occupied during operation is determined by the order of their operation. The application that runs first applies for space to store persistent data first.

[0076] The deadlock scenario is described as follows:

[0077] 1) After APP2 starts a transaction, it locks page 1 and page 3, and switches to APP1 before the transaction is completed.

[0078] 2) After APP1 starts a transaction and locks the page 2 resource, it continues to operate on page 1. Finding that page 1 is locked, it enters the blocking queue and switches to APP2.

[0079] 3) APP2 continues to execute the operation on page 2. Page 2 is locked and it enters the blocking queue. A deadlock occurs.

[0080] In this embodiment, as Figure 3 shown, before a transaction performs read / write operations, first judge the number of transactions started in the current virtual machine, which is recorded by a global counter transaction_count;

[0081] Whenever a new transaction is started, increment the value of the global counter transaction_count by 1;

[0082] Whenever a transaction ends, decrement the value of the global counter transaction_count by 1;

[0083] Before determining whether there is a risk of deadlock, first check the value of the global counter transaction_count. If transaction_count <= 1, it indicates that only the current transaction A is being executed in the virtual machine. At this time, it is determined that no deadlock will occur, and transaction A is directly allowed to perform read and write operations.

[0084] Moreover, in each write operation before transaction A ends, back up the data of the write operation and maintain a list of resources occupied by transaction A to facilitate resource recovery and deadlock handling when needed.

[0085] Among them, the storage structure of the transaction occupied resource list is shown in Table (1): A page number can only be exclusively occupied by one transaction.

[0086]

[0087] When the value of the global counter transaction_count is greater than 1, it indicates that two or more transactions are running in the virtual machine. At this time, there is a risk of deadlock and further detection is required.

[0088] According to the target address and read / write length of transaction A, count the target resource list that transaction A is about to read and write. The target resource list includes consecutive page numbers, such as page 11, page 12, and page 13. The page numbers read and written at one time must be consecutive.

[0089] Detect the obtained target resource list of transaction A. By checking the resource lists occupied by all running transactions, determine whether the target resources that transaction A is about to read and write are not occupied by other transactions.

[0090] If the target resources that transaction A is about to read and write are not occupied by other transactions, directly allow transaction A to perform read and write operations.

[0091] If one or more of the target resources that transaction A is about to read and write are occupied by other transactions, return the transaction ID corresponding to the first occupied resource, denoted as transaction B, and perform a resource detection on transaction B to determine whether there is a risk of deadlock and adopt corresponding deadlock avoidance strategies according to the detection results.

[0092] Further explanation: If the resources required for this read / write operation are pages 11, 12, and 13, and pages 11 and 12 are not occupied while page 13 is occupied, then the transaction ID of the transaction that occupies page 13 is returned. If both pages 12 and 13 are occupied, only the transaction ID that occupies page 12 is returned. This read / write operation can only proceed when all resources are unoccupied.

[0093] In this embodiment, the following pre-detection steps are further included:

[0094] When it is determined that one or more of the target resources to be read / written by transaction A are occupied by other transactions, starting from the transaction B that occupies the resources, traverse the resource waiting graph to check whether there is a node of the current transaction A in the resource waiting graph.

[0095] Among them, since a transaction is started in a virtual thread and each transaction can only be blocked by one transaction, the relevant resource waiting relationships are stored in the virtual thread control block;

[0096] During the traversal, if a node of transaction A is found, it indicates that there is a dependency relationship between transaction A and transaction B, and this dependency relationship may form a loop, that is, there is a risk of deadlock; at this time, handle it according to the deadlock avoidance strategy to avoid the occurrence of deadlock;

[0097] If no node of transaction A is found, it means that the dependency relationship between transaction A and transaction B will not form a loop. At this time, build a dependency relationship in the virtual thread control block, record the ID of transaction B in the waiting transaction ID field waiting for transaction A, and set the virtual thread where transaction A is located to the blocked state, and wait for transaction B to release the resources and then wake up transaction A to continue execution.

[0098] In this embodiment, as Figure 4 shown, define the structure of the virtual thread control block, including:

[0099] Transaction ID field: used to mark the transaction ID in the current virtual thread when starting a transaction.

[0100] Waiting transaction ID field: used to store the ID of other transactions that occupy the resource when checking shared resources.

[0101] During the transaction startup process, assign a unique transaction ID to each transaction and mark it in the transaction ID field of its corresponding virtual thread control block.

[0102] During the shared resource check process, if it is found that the target resource is occupied by other transactions, store the transaction ID of the transaction that occupies the resource in the waiting transaction ID field of the virtual thread control block corresponding to the transaction that requests the resource.

[0103] Based on the information in the transaction ID and waiting transaction ID fields, combined with the resource request and occupancy relationships between transactions, a resource waiting graph is dynamically constructed to represent the waiting and dependency relationships between transactions for deadlock detection and avoidance.

[0104] In this embodiment, two types of resource waiting graphs can be constructed according to the transaction waiting relationships, as Figure 5 shown, which are divided into a cyclic resource waiting graph and an acyclic resource waiting graph.

[0105] During the process of constructing or updating the resource waiting graph, check whether the node of the current transaction A is included in the resource waiting graph:

[0106] If the node of transaction A is not included in the resource waiting graph, it means that the dependency relationship formed between transaction A and transaction B that occupies the resources it needs will not form a loop; in this case, build the dependency relationship in the virtual thread control block corresponding to transaction A, and record the ID of transaction B in the waiting transaction ID field; place the virtual thread where transaction A is located into the blocked state, and wait for transaction B to release the resources and then wake up transaction A to continue execution.

[0107] If the node of transaction A is already included in the resource waiting graph, it means that the dependency relationship formed between transaction A and transaction B that occupies the resources it needs will form a loop, that is, there is a deadlock risk, then a deadlock avoidance strategy is adopted to avoid the occurrence of deadlocks. The processing strategy is a rollback + retry + exception handling strategy to ensure the stability and reliability of the system, ensure that transactions can be executed smoothly in the expected order, and avoid system deadlocks or performance degradation caused by resource competition.

[0108] Specifically, when it is detected that there is a loop in the resource waiting graph, that is, there is a deadlock risk, a deadlock avoidance strategy is adopted to avoid deadlocks;

[0109] Find a transaction with a lower priority in the loop for rollback processing, where the smaller the priority value, the higher the priority;

[0110] If the transaction with a lower priority found is transaction C, then execute the following steps:

[0111] Roll back transaction C to make the program state return to the state before transaction C was executed;

[0112] Reconstruct the waiting relationship between transaction A and transaction B for subsequent resource competition and transaction execution.

[0113] If the transaction with a lower priority found in the loop is still transaction A, then execute the following processing:

[0114] Check whether the number of retry times in transaction A has reached the upper limit, and the default upper limit of the number of retry times is 5 times;

[0115] When the retry counter is greater than or equal to 5 times, it indicates that Transaction A has no chance to retry. At this time, a transaction exception is thrown to the application to end the execution of Transaction A;

[0116] If the number of retries does not reach the upper limit, the following sub-steps are executed:

[0117] Roll back Transaction A, release all resources occupied by Transaction A, and notify other transactions waiting for Transaction A to re-compete for resources to run;

[0118] The program state is rolled back to the position where Transaction A just started to execute, so that Transaction A can retry;

[0119] The retry count of Transaction A is incremented to record the number of times Transaction A has tried to execute;

[0120] Yield the execution right to allow other transactions to continue to execute to ensure the effective utilization of system resources and the sequential execution of transactions.

[0121] This embodiment proposes an innovative transaction processing scheme, especially for the multi-virtual thread virtual machine environment in resource-constrained devices. By constructing a resource waiting graph and combining appropriate deadlock resolution strategies, the deadlock problem between transactions is effectively avoided.

[0122] Furthermore, by constructing a resource waiting graph in real time, this embodiment can dynamically monitor the resource dependency relationships between transactions and timely detect potential deadlock risks. Combining strategies such as transaction rollback, resource release, and transaction priority, this embodiment can take preventive measures before a deadlock occurs to ensure the smooth execution of transactions and effectively avoid system deadlocks caused by deadlocks.

[0123] Furthermore, through a reasonably designed transaction processing mechanism, this embodiment ensures the stable execution of multiple concurrent transactions in resource-constrained devices. During the transaction execution process, this embodiment can dynamically adjust the execution order of transactions and give priority to processing high-priority transactions, thereby improving the overall stability of the system.

[0124] Furthermore, the transaction processing scheme of this embodiment strictly follows the atomicity, consistency, isolation, and durability (ACID) principles to ensure the consistency and integrity of data during transaction execution. Through the transaction rollback mechanism, this embodiment can restore to the state before the transaction started when the transaction execution fails, ensuring that the data consistency is not affected.

[0125] Furthermore, this embodiment particularly considers the application scenarios and operating environment requirements of resource-constrained devices and designs a transaction processing mechanism suitable for devices with low memory and low computing power. By local resource detection and real-time deadlock prevention, this embodiment reduces resource consumption and computational complexity, enabling efficient and stable execution of transactions in resource-constrained devices.

[0126] Furthermore, in combination with the virtual thread scheduler, this embodiment can reasonably roll back the program and yield the execution right, enabling transactions with lower priorities to yield resources first and transactions with higher priorities to execute first, thereby improving the response speed and execution efficiency of the application. By optimizing the transaction processing flow and reducing the risk of deadlocks, this embodiment greatly enhances the application performance and reliability in resource-constrained devices, providing strong guarantee for the stable operation of the devices.

[0127] The technical features of the above embodiments can be combined arbitrarily. For the sake of concise description, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, it should be considered as the scope recorded in this specification.

[0128] The above embodiments are only the preferred embodiments of the present invention and cannot be used to limit the scope of protection of the present invention. Any non-substantial changes and substitutions made by those skilled in the art based on the present invention fall within the scope of protection required by the present invention.

Claims

1. A method for multi-transaction deadlock detection and handling in resource-constrained devices, characterized in that, It includes the following steps: During the execution of a transaction, construct a resource waiting graph, which is used to record the waiting relationships between transactions to reflect the occupancy of shared resources by each transaction and the dependencies between them; Before each read / write operation of a transaction, by detecting the dependency relationship between the current transaction and the target resource and combining with the resource waiting graph, determine in real time whether the execution of the current transaction will cause the occurrence of a deadlock risk; When a deadlock risk is detected, adopt a deadlock avoidance strategy of priority processing, transaction rollback, transaction retry, and exception handling to avoid the occurrence of a deadlock.

2. The method according to claim 1, wherein: The comprehensive strategy specifically includes: select a transaction with a lower priority for rollback according to the priorities of each transaction, release the resources it occupies to break the deadlock dependency cycle; if the retry count of the rolled-back transaction does not reach the preset upper limit, allow the transaction to retry execution after rollback; if the retry count of the rolled-back transaction reaches the preset upper limit, throw an exception and end the transaction.

3. The method according to claim 1, wherein: Before a transaction performs a read / write operation, first judge the number of transactions with transactions started in the current virtual machine, and record it through a global counter transaction_count; Whenever a new transaction is started, increment the value of the global counter transaction_count by 1; Whenever a transaction ends, decrement the value of the global counter transaction_count by 1; Before judging whether there is a deadlock risk, first check the value of the global counter transaction_count. If transaction_count <= 1, it indicates that only the current transaction A is being executed in the virtual machine. At this time, it is determined that no deadlock will occur, and directly allow transaction A to perform read / write operations; Moreover, during each write operation before transaction A ends, back up the data of the write operation, and at the same time maintain a list of resources occupied by transaction A to facilitate resource recovery and deadlock handling when needed.

4. The method according to claim 3, wherein: When the value of the global counter transaction_count is greater than 1, it indicates that two or more transactions are running in the virtual machine. At this time, there is a risk of deadlock occurring and further detection is required; According to the target address and read / write length of transaction A, count the target resource list that transaction A is about to read / write, and the target resource list includes consecutive page numbers; Detect the obtained target resource list of transaction A, and by checking the resource lists occupied by all running transactions, judge whether the target resources that transaction A is about to read / write are not occupied by other transactions; If the target resources that transaction A is about to read / write are not occupied by other transactions, directly allow transaction A to perform read / write operations; If one or more of the target resources that transaction A is about to read or write are occupied by other transactions, return the transaction ID corresponding to the first occupied resource, denoted as transaction B, and perform a resource detection on transaction B to determine whether there is a deadlock risk, and adopt corresponding deadlock avoidance strategies according to the detection results.

5. The method according to claim 4, characterized in that, It also includes the following pre-detection steps: When it is determined that one or more of the target resources that transaction A is about to read or write are occupied by other transactions, starting from the transaction B that occupies the resources, traverse the resource waiting graph to find whether there is a node of the current transaction A in the resource waiting graph; Among them, since a transaction is started in a virtual thread and each transaction can only be blocked by one transaction, the relevant resource waiting relationships are stored in the virtual thread control block; During the traversal process, if a node of transaction A is found, it means that there is a dependency relationship between transaction A and transaction B, and this dependency relationship may form a loop, that is, there is a deadlock risk; at this time, handle it according to the deadlock avoidance strategy to avoid the occurrence of deadlock; If a node of transaction A is not found, it means that the dependency relationship between transaction A and transaction B will not form a loop. At this time, build a dependency relationship in the virtual thread control block, record the ID of transaction B in the waiting transaction ID field waiting for transaction A, and set the virtual thread where transaction A is located to the blocked state, and wait for transaction B to release the resources and then wake up transaction A to continue execution.

6. The method according to claim 5, characterized in that: Define the structure of the virtual thread control block, including: Transaction ID field: used to mark the transaction ID in the current virtual thread when starting a transaction; Waiting transaction ID field: used to store the IDs of other transactions that occupy this resource during shared resource checking; During the transaction startup process, assign a unique transaction ID to each transaction and mark it in the transaction ID field of its corresponding virtual thread control block; During the shared resource checking process, if it is found that the target resource is occupied by other transactions, store the transaction ID of the transaction that occupies this resource in the waiting transaction ID field of the virtual thread control block corresponding to the transaction that requests this resource; Through the information of the transaction ID and the waiting transaction ID field, combined with the resource request and occupation relationships between transactions, dynamically construct a resource waiting graph to represent the waiting and dependency relationships between transactions for deadlock detection and avoidance.

7. The method according to claim 6, characterized in that: During the process of constructing or updating the resource waiting graph, check whether the resource waiting graph contains a node of the current transaction A: If the resource waiting graph does not contain a node of transaction A, it means that the dependency relationship formed between transaction A and transaction B that occupies the resources it needs will not form a loop; In this case, build a dependency relationship in the virtual thread control block corresponding to transaction A, and record the ID of transaction B in the waiting transaction ID field; Set the virtual thread where transaction A is located to the blocked state, and wait for transaction B to release the resources and then wake up transaction A to continue execution.

8. The method according to claim 7, characterized in that: If the resource waiting graph already contains a node for transaction A, it indicates that the dependency relationship formed between transaction A and transaction B, which occupies the resources required by transaction A, will form a loop, that is, there is a risk of deadlock; Then the deadlock avoidance strategy is adopted to avoid the occurrence of deadlock.

9. The method according to claim 1, characterized in that: When it is detected that there is a loop in the resource waiting graph, that is, there is a risk of deadlock, the deadlock avoidance strategy is adopted to avoid deadlock; Find a transaction with a lower priority in the loop for rollback processing, where the smaller the priority value, the higher the priority; If the transaction with a lower priority found is transaction C, then the following steps are executed: Roll back transaction C to make the program state roll back to the state before transaction C was executed; Reconstruct the waiting relationship between transaction A and transaction B for subsequent resource competition and transaction execution.

10. The method according to claim 9, characterized in that: If the transaction with a lower priority found in the loop is still transaction A, then the following processing is executed: Check whether the number of retry attempts in transaction A has reached the upper limit, and the default upper limit of the number of retry attempts is 5 times; When the retry counter is greater than or equal to 5 times, it means that transaction A has no chance to retry. At this time, a transaction exception is thrown to the application program to end the execution of transaction A; If the number of retry attempts has not reached the upper limit, then the following sub-steps are executed: Roll back transaction A, release all resources occupied by transaction A, and notify other transactions waiting for transaction A to re-compete for resources to run; The program state rolls back to the position where transaction A just started to execute, so that transaction A can retry execution; The number of retry attempts of transaction A is incremented to record the number of times transaction A has attempted to execute; Yield the execution right to allow other transactions to continue to execute to ensure the effective utilization of system resources and the sequential execution of transactions.

Images