A resource scheduling method based on transaction events and electronic equipment

Abstract

The application discloses a kind of resource scheduling method and electronic equipment based on transaction event.The method is applied to electronic equipment, method includes: when listening to transaction event process, control transaction protection mode to open, transaction event process includes transaction state change process;In the transaction protection mode open state, the task control block of each background task is acquired, and the task control block at least includes the task interrupt attribute for identifying background task;According to task interrupt attribute, the resource scheduling control is carried out to each background task, to ensure that transaction event process proceeds smoothly.The application drives transaction protection mode to open by transaction event, guarantees payment transaction priority execution;Through task control block, the interrupt attribute of background task is uniformly managed, and differentiated resource scheduling is realized, which overcomes the defect that task cannot be recovered caused by simple suspension, and improves the stability and resource utilization of payment terminal.

Description

Technical Field

[0001] This invention relates to the field of resource scheduling technology, and in particular to a resource scheduling method and electronic device based on transaction events. Background Technology

[0002] In related technologies, transaction terminals need to process transaction tasks. However, transaction terminals themselves also have background tasks. When background tasks are executed concurrently with transaction business, high-load background tasks can easily lead to payment delays, response delays, or even transaction failures, affecting transaction stability and continuity. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide a resource scheduling method and electronic device based on transaction events, so as to realize the coordinated scheduling of transaction priority protection and background task security.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A resource scheduling method based on transaction events, characterized in that it is applied to electronic devices, and the method includes: When a transaction event process is detected, the transaction protection mode is activated, and the transaction event process includes the transaction status change process. When the transaction protection mode is enabled, obtain the task control block for each background task. The task control block includes at least a task interruption attribute for identifying the background task. Based on the task interruption attribute, resource scheduling control is performed on each background task to ensure the smooth progress of the transaction event.

[0005] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: An electronic device includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor executes the computer program to implement the steps of the above-described resource scheduling method based on transaction events.

[0006] The beneficial effects of this invention are as follows: By monitoring the transaction event process, when a transaction event process is detected, the transaction protection mode is activated, providing a priority execution environment for transaction services and reducing the risk of payment delays and transaction failures; by defining the transaction event process as including the transaction state change process, dynamic perception and response to the entire transaction event process are achieved; by acquiring the task control block containing the task interruption attribute of each background task, unified management of the interruption characteristics of background tasks is achieved; by performing resource scheduling control on each background task according to the task interruption attribute, dynamic collaborative scheduling between transaction services and background tasks is achieved; while ensuring smooth transaction execution, the execution needs of background tasks are also taken into account. Using the solution of this application, when background tasks and transaction services are executed concurrently, the background tasks will perform resource scheduling control based on the task interruption attribute, thereby avoiding the problem of payment delays, response delays, or even transaction failures caused by high-load tasks, which affect the stability and continuity of transactions; this solution achieves a substantial leap from mutual conflict to collaborative coexistence between background tasks and transaction services, providing stability and resource utilization efficiency for smart payment terminals in high-concurrency scenarios. Attached Figure Description

[0007] Figure 1 A flowchart illustrating the steps of a resource scheduling method based on transaction events, provided in an embodiment of the present invention; Figure 2 An overall architecture diagram of a resource scheduling system based on transaction events provided in an embodiment of the present invention; Figure 3 A flowchart illustrating the steps of a transaction protection mode provided in an embodiment of the present invention; Figure 4 A task control block lifecycle state transition diagram provided in an embodiment of the present invention; Figure 5 A flowchart illustrating the steps of a system upgrade task phase control provided in this embodiment of the invention; Figure 6 This is a schematic diagram of an operating system-level resource mapping mechanism provided in an embodiment of the present invention; Figure 7 A flowchart illustrating the steps of transaction resource preemption and timing control provided in this embodiment of the invention; Figure 8 A flowchart illustrating the steps of transaction timeout protection and anomaly recovery provided in this embodiment of the invention; Figure 9 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0008] To make the technical problems, technical solutions, and beneficial effects to be solved by this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and are not intended to limit the scope of this application.

[0009] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0010] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0011] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0012] In related technologies, with the continuous improvement of the intelligence level of POS terminals, modern POS devices are no longer only used for payment transactions, but also support a variety of ecosystem capabilities such as OTA (Over-the-Air Technology) upgrades, application installation and updates, data synchronization, marketing displays, secondary screen content rendering, and the operation of third-party extended applications. During the actual operation of a POS terminal, transaction processing and backend ecosystem tasks typically share system resources such as CPU, memory, network, and I / O. Payment transactions have extremely high requirements for real-time performance, stability, and continuity, while backend ecosystem tasks often involve high resource consumption such as network downloads, storage writes, application installations, and system upgrades. When backend tasks and transaction processing are executed concurrently, the following problems can easily occur: OTA upgrades consume network bandwidth, affecting payment communication; backend disk write operations cause transaction thread response delays; application installation or upgrades consume CPU resources, causing payment lag; backend tasks trigger system restarts, affecting transaction continuity; concurrent execution of multiple tasks leads to abnormally high system load; and system switching or upgrade operations during transactions pose system risks.

[0013] To address the aforementioned issues, POS terminals in related technologies typically employ simple methods such as pausing background tasks or statically restricting task execution during transactions to ensure the priority execution of payment transactions. However, they lack a unified resource scheduling mechanism and suffer from poor scheduling flexibility.

[0014] For example, when a transaction event occurs, related technologies often directly suspend all background tasks to prioritize the transaction event, failing to distinguish the interruptibility characteristics of different background tasks. This results in critical tasks (such as OTA partition writing and application installation submission) being forcibly interrupted and unable to be safely resumed, potentially causing system file corruption or upgrade failures. Simultaneously, for tasks that can be interrupted (such as data synchronization, ad updates, and configuration fetching), there is a lack of unified suspension and resumption management, making it impossible to resume execution from where it left off, thus reducing the execution efficiency of background tasks. Furthermore, existing technologies cannot perceive the specific stage of a background task (such as download, verification, or disk writing), leading to a uniform suppression strategy for all background tasks throughout the entire transaction duration. Even after the transaction ends, there is no way to differentiate and resume them, resulting in low system resource utilization and difficulty in guaranteeing the completion of background tasks. Moreover, existing transaction scheduling strategies lack a dynamic adjustment mechanism based on transaction status. When the transaction protection mode lasts for too long, background tasks are suppressed for extended periods, potentially causing resource starvation or a complete system freeze.

[0015] Furthermore, existing POS terminals, besides simply suppressing background tasks during transactions, lack the ability to continuously monitor and perceive the progress of transaction events. Specifically, current solutions only trigger resource adjustments at the start of a transaction, failing to dynamically schedule resources in response to changes in transaction status (such as amount confirmation, payment success, payment failure, etc.) during the transaction process. They also cannot promptly restore system resource status when transaction processes are abnormal (such as application crashes, communication link disconnections, or heartbeat timeouts), resulting in the system remaining in a resource-suppressed state for an extended period after the transaction ends abnormally, affecting the normal operation of background tasks. Simultaneously, resource scheduling decisions in these technologies lack comprehensive awareness of background task interruption attributes, execution stages, and transaction status, failing to achieve a dynamic balance between transaction operations and background ecosystem tasks. This leads to decreased stability and reliability of payment terminals in high-concurrency or complex task scenarios. While cloud server upgrade scenarios have resource scheduling mechanisms, they deal with planned, predictable tasks and typically employ exclusive resource allocation. In contrast, POS terminal payment transactions have sudden, random, and high real-time requirements, and the terminal's own resources are limited, making it impossible to directly apply server-side scheduling strategies.

[0016] To address the aforementioned problems, this application provides a resource scheduling method and electronic device based on transaction events. This method provides a prioritized execution environment for payment transactions by monitoring transaction event processes and controlling the activation of transaction protection modes; it achieves unified management of background task interruption characteristics by acquiring a task control block containing task interruption attributes; and it realizes dynamic collaborative scheduling between transaction services and background tasks by performing resource scheduling control on each background task according to the task interruption attributes. This overcomes the shortcomings of simply pausing background tasks, which can lead to the inability to safely resume critical tasks, ensuring the smooth execution of payment transactions while also meeting the execution needs of background tasks.

[0017] The following describes in detail a resource scheduling method based on transaction events according to the present invention, with reference to the appendix. Figure 1 This includes steps 110 to 130.

[0018] Step 110: When a transaction event process is detected, control the transaction protection mode to be activated. The transaction event process includes the transaction status change process.

[0019] For example, when an electronic device detects a transaction event process through the transaction service interface, it activates the transaction protection mode. This transaction event process includes transaction start events, amount confirmation events, payment success events, payment failure events, and transaction cancellation events.

[0020] Step 120: With the transaction protection mode enabled, obtain the task control block for each background task. The task control block includes at least the task interruption attribute used to identify the background task.

[0021] For example, when the transaction protection mode is enabled, the electronic device obtains the creation event of each background task, retrieves the task interruption attribute of the background task from the creation event, and generates or matches the task control block based on the task interruption attribute of the background task.

[0022] Step 130: Based on the task interruption attribute, perform resource scheduling control on each background task to ensure the smooth progress of the transaction event. For example, when the transaction protection mode is enabled, the electronic device determines the resource scheduling strategy corresponding to each background task based on the task interruption attribute in the task control block, and performs resource scheduling control on each background task according to the resource scheduling strategy to ensure the smooth progress of the transaction event; "smooth" means that the transaction event process can obtain priority scheduling system resources during execution, is not interfered with by background tasks, and successfully completes execution.

[0023] In this way, this application provides a priority execution environment for payment transactions by monitoring the transaction event process and controlling the activation of the transaction protection mode. This ensures that the transaction process can obtain system resources in a timely manner, effectively avoiding the risk of payment delays and transaction failures caused by background tasks occupying resources. By monitoring the transaction event process, including the transaction state change process, dynamic perception and continuous response to the entire transaction process are achieved, not limited to the start of the transaction, but also triggering resource scheduling in the intermediate and abnormal states of the transaction. By obtaining the task control block of each background task, unified management and centralized identification of the interruption characteristics of background tasks are achieved, providing a data foundation for subsequent differentiated scheduling. By controlling resource scheduling for each background task according to the task interruption attributes, differentiated scheduling of interruptible and non-interruptible tasks is achieved. This overcomes the shortcomings of related technologies, such as simply pausing all background tasks, which may lead to the inability to safely resume critical tasks, damage to system files, or upgrade failures. It ensures the smooth progress of the transaction process while taking into account the execution needs of background tasks. This improves the stability and resource utilization efficiency of the payment terminal in high-concurrency scenarios.

[0024] In one embodiment of this application, step 110, when a transaction event process is detected, controls the transaction protection mode to be activated, including steps 210 and 220. The electronic device includes a transaction service interface, which is used for transmitting transaction event processes between the transaction application and the system, enabling the system to receive transaction event processes sent by the transaction application through this interface.

[0025] Step 210: Monitor the transaction event progress sent by the trading application through the transaction service interface. For example, when a transaction status change occurs, the trading application sends a transaction event progress to the system through the transaction service interface, and the system receives the transaction event progress through the transaction service interface. This transaction status change includes transaction start, transaction confirmation, transaction success, transaction failure, or transaction cancellation, etc. When any of the above status changes occur in the trading application, the system can immediately detect the arrival of the transaction event progress through the transaction service interface.

[0026] Step 220: Alternatively, the system can obtain the transaction event process transmitted to the resource scheduling module via the system event distribution mechanism. For example, when a transaction event process is detected through the aforementioned transaction service interface or system event distribution mechanism, the electronic device activates the transaction protection mode. After the transaction application sends the transaction event process to the system through the transaction service interface, the system will also distribute the transaction event process through the system event distribution mechanism to the resource scheduling module. The electronic device can then listen for and obtain the transaction event process through the system event distribution mechanism.

[0027] In this way, this application monitors the transaction event process through two methods: a transaction service interface and a system event distribution mechanism. On the one hand, it directly receives transaction event progress notifications from the transaction application through the transaction service interface, ensuring real-time awareness of the transaction event process. On the other hand, it monitors at the system level through the system event distribution mechanism, avoiding event loss due to an abnormal single monitoring path of the transaction service interface. The two methods complement each other, ensuring that the system can timely and reliably detect the arrival of the transaction event process, thereby triggering subsequent resource scheduling processes and improving the real-time performance and reliability of transaction event process monitoring.

[0028] In one embodiment of this application, the method 100 further includes steps 230 to 270, which may be performed after step 110.

[0029] Step 230: When a transaction event process sent by a transaction application is detected through the transaction service interface, the trustworthiness of the transaction application is verified. For example, when a transaction event process sent by a transaction application is detected through the transaction service interface, the electronic device obtains the identity information of the transaction application and performs a trustworthiness verification on the transaction application. This includes verifying the package name, UID, and digital signature information of the transaction application, as well as matching and verifying the transaction application against the whitelist of transaction applications issued by the backend device management platform to confirm whether the transaction application is a legitimate and trustworthy transaction application.

[0030] Step 240: If the trustworthiness verification fails, the transaction application is prohibited from triggering the transaction protection mode. For example, if the transaction application's package name, UID, or digital signature information verification fails, or if the transaction application is not on the transaction application whitelist issued by the backend device management platform, the transaction application is prohibited from triggering the transaction protection mode.

[0031] Step 250: If the trustworthiness verification passes, a unique transaction session identifier is generated for the transaction event process sent by the transaction application, and the continuity of the transaction event process's state is verified. For example, if the trustworthiness verification of the transaction application passes, the electronic device generates a unique transaction session identifier for the transaction event process. This verification of the continuity of the transaction event process's state includes verifying whether the transaction state is continuous and whether there are any jumps or interruptions, to avoid forging the transaction state.

[0032] Step 260: If the state continuity check fails, the transaction application is prohibited from triggering the transaction protection mode. For example, if there is a state transition or interruption in the transaction event process, such as the transaction event process jumping directly to payment success without amount confirmation after it starts, the state continuity check is determined to have failed, and the transaction application is prohibited from triggering the transaction protection mode.

[0033] Step 270: If the state continuity check passes, the transaction application is allowed to trigger the transaction protection mode. For example, if the state continuity check of the transaction event process passes, the electronic device allows the transaction application to trigger the transaction protection mode.

[0034] In this way, this application ensures that only legitimate and trustworthy transaction applications can trigger the transaction protection mode through trustworthiness verification, preventing malicious applications or unauthorized calls from seizing system resources and ensuring transaction security; through transaction session identifier and state continuity verification, it ensures the authenticity and continuity of the transaction event process, preventing the forgery of transaction status or unauthorized triggering of the transaction protection mode, thereby improving the security and reliability of the transaction protection mode triggering.

[0035] In one embodiment of this application, step 120 includes steps 310 to 330.

[0036] Step 310: Obtain the creation event of each background task through the process management mechanism, and extract the identification information of the background task from the creation event. For example, the electronic device monitors the creation event of each background task in the system in real time through the process management mechanism. When a new background task is created, the process management mechanism captures the creation event and extracts the identification information of the background task from the creation event. This identification information is used to uniquely distinguish different background tasks.

[0037] Step 320: Generate or match a task control block based on the background task's identification information. For example, after the electronic device obtains the background task's identification information, it checks whether a task control block corresponding to that identification information already exists in the system; if it does not exist, a new task control block is generated for the background task based on that identification information; if it already exists, the existing task control block is matched to the background task.

[0038] Step 330: Associate the task control block with a corresponding resource control unit. The resource control unit is used to constrain the resource usage of the background task. For example, the electronic device associates the task control block with a resource control unit, which corresponds one-to-one with the background task and is used to constrain the CPU, input / output, and network resource usage of the background task.

[0039] In this way, the creation events of background tasks are obtained in real time through the process management mechanism and the identification information is extracted, ensuring that each background task can be detected and identified in a timely manner; by generating or matching the corresponding task control block based on the identification information, the background tasks are uniformly encapsulated and managed; by associating the task control block with the corresponding resource control unit, the resource usage of each background task can be independently constrained and controlled, providing a basis for subsequent differentiated resource scheduling and improving the granularity and flexibility of resource scheduling.

[0040] In one embodiment of this application, step 130 performs resource scheduling control on each background task according to the task interruption attribute, including steps 410 and 420.

[0041] Step 410: When the task interruption attribute indicates that the background task is allowed to be interrupted, the task state of the background task is switched to the suspended state, and the execution context of the background task is saved. For example, when the task interruption attribute of the background task indicates that the background task is allowed to be interrupted, the electronic device switches the task state of the background task from the running state to the suspended state, suspends the execution of the background task, and saves the current execution context of the background task to the storage area. The execution context includes the current execution progress, breakpoint position, and intermediate data of the background task, so as to resume execution later.

[0042] Step 420: When the task interruption attribute indicates that the background task is not allowed to be interrupted, limit the resource usage level of the background task. For example, when the task interruption attribute of a background task indicates that the background task is not allowed to be interrupted, the electronic device does not suspend the background task, but limits the resource usage level of the background task. This is done by reducing the CPU scheduling weight of the background task, limiting the input / output bandwidth, or limiting the network transmission rate, thereby reducing the system resource consumption of the background task.

[0043] In this way, background tasks are scheduled differently based on their interruption attributes. For background tasks that can be interrupted, resources are completely released by suspending them and saving their context. For background tasks that cannot be interrupted, resource consumption is reduced while ensuring their continuous execution by limiting their resource consumption levels. This approach not only guarantees the resource requirements of the transaction process but also takes into account the execution characteristics of different types of background tasks, avoiding the problem of critical tasks failing due to simply and crudely pausing all background tasks.

[0044] In one embodiment of this application, the task control block includes at least a task interruption attribute for representing a background task. Step 120, in the transaction protection mode enabled state, obtains the task control block for each background task, including steps 510 and 520.

[0045] Step 510: When the task interruption attribute indicates that the background task is allowed to be interrupted, the task control block of the suspended background task is read, and the execution context of the background task saved in the task control block is used to resume the execution of the background task. The background task is then re-added to the task scheduling queue. The task control block in the electronic device is used to store the execution context of the suspended background task so that the execution of the background task can be resumed later. For example, when the transaction protection mode is enabled, when the transaction event process is detected to have ended, the electronic device exits the transaction protection mode. For background tasks whose interruption attribute is indicated as allowed to be interrupted and are in a suspended state, the electronic device reads the task control block of the background task, obtains the previously saved execution context from the task control block, resumes the execution of the background task according to the execution context, and re-adds the background task to the task scheduling queue so that the background task can continue execution from the breakpoint when it was suspended.

[0046] Step 520: When the task interruption attribute indicates that the background task is not allowed to be interrupted, the resource usage level restriction on the background task is lifted. For example, for a background task whose interruption attribute is indicated as not allowed to be interrupted and whose resource usage level is restricted, the electronic device lifts the resource usage level restriction on the background task, restores the CPU scheduling weight, input / output bandwidth and network transmission rate of the background task, and enables the background task to resume normal execution.

[0047] In this way, by resuming the execution of background tasks that can be interrupted after the transaction event process ends, using the execution context saved in the task control block, and re-adding them to the scheduling queue, the system achieves the ability to resume execution of tasks from the beginning, thus avoiding the waste of resources and time caused by re-executing tasks from the beginning. For background tasks that cannot be interrupted, the system removes the restrictions on resource usage levels, allowing them to return to normal operation, ensuring that background tasks can be resumed in a timely manner after the transaction ends, and improving the overall operating efficiency of the system.

[0048] In one embodiment of this application, the application further includes steps 610 to 630 when the transaction protection mode is enabled in step 120.

[0049] Step 610: Set processor resource acquisition priority for the transaction process. For example, when the transaction protection mode is enabled, the electronic device sets a higher processor resource acquisition priority for the transaction process executing the transaction event process than for background tasks, so that the transaction process can obtain processor resources before background tasks during processor resource scheduling.

[0050] Step 620: Assign an independent network transmission channel and input / output processing priority permissions to the trading process. For example, the electronic device assigns an independent network transmission channel to the trading process to ensure that the network communication of the trading process does not compete with other background tasks for network bandwidth; at the same time, it assigns input / output processing priority permissions to the trading process so that the input / output operations of the trading process are executed first.

[0051] Step 630: Restrict the execution of system restart operations, application security operations, and system upgrade partition switching operations. For example, when the electronic device is in transaction protection mode, restrict the execution of system restart operations to prevent system restarts from interrupting transactions; restrict the execution of application installation operations to prevent the application installation process from consuming a large amount of CPU and I / O resources and affecting the transaction process; and restrict the execution of system upgrade partition switching operations to prevent system restarts triggered during upgrade partition switching from affecting the continuity of the transaction process.

[0052] In this way, by setting processor resource acquisition priority, allocating independent network transmission channels, and prioritizing input / output processing permissions for the transaction process in transaction protection mode, the transaction process can be guaranteed priority in processor, network, and input / output resources. By restricting the execution of system restart operations, application installation operations, and upgrade partition switching operations, interference from system-level critical operations on the transaction process is avoided, further ensuring the smooth execution of the transaction process and improving the stability and continuity of transactions.

[0053] In one embodiment of this application, step 130 performs resource scheduling control on each background task according to the task interruption attribute, and further includes steps 710 to 740.

[0054] Step 710: When the background task is a system upgrade task, obtain the current execution stage of the system upgrade task. For example, the electronic device identifies the type of background task through the task control block. When the background task is a system upgrade task, the electronic device obtains the current execution stage of the system upgrade task. The execution stages of the system upgrade task include at least one of the following: download stage, verification stage, partition write stage, partition switch stage, and restart stage. Different stages have different tolerances for interruptions.

[0055] Step 720: If the execution phase is a download phase or a verification phase, then pause the execution of the system upgrade task or limit its resource usage. For example, when the system upgrade task is in the download phase, the electronic device pauses the download task or limits the network bandwidth used by the download task; when the system upgrade task is in the verification phase, the electronic device pauses the verification task or limits the CPU resources used by the verification task. The download and verification phases are interruptible phases; after pausing or limiting, execution can be resumed from the breakpoint without affecting the final completion of the system upgrade task.

[0056] Step 730: If the execution phase is a partition write phase or a partition switch phase, the continuous execution of the system upgrade task is maintained, and the resource consumption of the system upgrade task is limited. For example, when the system upgrade task is in the partition write phase or the partition switch phase, the electronic device maintains the continuous execution of the system upgrade task, while reducing the CPU scheduling weight of the system upgrade task and limiting the input / output bandwidth of the system upgrade task, so as to reduce its resource preemption on the transaction process and avoid direct interruption that could lead to system file corruption or upgrade failure.

[0057] Step 740: If the execution phase is a restart phase and an ongoing transaction event is detected, the system restart operation is delayed. For example, when a system upgrade task is in the restart phase, the electronic device checks whether an ongoing transaction event exists; if an ongoing transaction event exists, the system restart operation is delayed until the transaction event process is completed, in order to ensure transaction continuity.

[0058] In this way, by adopting differentiated resource control strategies according to different execution stages of the system upgrade task: during the download and verification stages, task execution is paused or restricted to release resources for the transaction process; during the partition writing and partition switching stages, task execution is maintained continuously and resource consumption is limited to ensure that critical operations are not interrupted while reducing the impact on the transaction process; when a transaction event is detected during the restart stage, the restart is delayed to avoid interruption of the transaction process, thus achieving the synergistic coexistence of system upgrade tasks and transaction business.

[0059] In one embodiment of this application, the method 100 further includes steps 810 and 820.

[0060] Step 810: Monitor the duration of the transaction protection mode. For example, after the electronic device activates the transaction protection mode, it starts a timer to record the duration of the transaction protection mode in real time. This duration is used to determine whether the transaction protection mode has been active for an extended period, thereby triggering subsequent resource fairness controls.

[0061] Step 820: When the duration exceeds a preset threshold, limit the resource consumption level of the transaction event and allow suspended background tasks to execute intermittently. For example, when the duration of the transaction protection mode exceeds a preset threshold (e.g., 30 seconds), the electronic device reduces the processor resource acquisition priority or resource consumption level of the transaction process, so that the transaction process no longer completely monopolizes system resources. At the same time, it allows suspended background tasks to intermittently obtain execution opportunities according to preset time intervals or priority order, so as to avoid the background tasks being suppressed for a long time, resulting in resource starvation or the entire system freezing.

[0062] In this way, by monitoring the duration of the transaction protection mode and limiting the resource consumption level of transaction events when the duration exceeds a preset threshold, the problem of background tasks being suppressed for a long time and unable to make progress, leading to resource starvation or system-wide freeze, is avoided. By allowing suspended background tasks to execute intermittently, it is ensured that background tasks still have a certain execution opportunity when the transaction protection mode lasts too long, thereby improving the fairness of the system and the overall operating efficiency.

[0063] The following describes the application embodiments of this application in detail. First, the modules included in the electronic device in the embodiments of this application are described: A unified resource scheduler is used to receive transaction event processes, control the activation or deactivation of transaction protection mode, and, when transaction protection mode is enabled, obtain the task control block for each background task through the task control block manager, and perform resource scheduling control for each background task based on the task interruption attribute in the task control block. This is equivalent to steps 110 to 130 above.

[0064] The Task Control Block Manager is used to obtain the creation event of each background task through the process management mechanism, generate or match a corresponding task control block for each background task, and the task control block includes at least a task interruption attribute to identify whether the background task is allowed to be interrupted. The task control block is bound to a resource control group to constrain the resource usage of the background task. This is equivalent to steps 120, 310 to 330 above.

[0065] The resource control group is used to allocate and restrict CPU, I / O, and network resources for background tasks and transaction processes. This includes setting CPU resource acquisition priorities for transaction processes, allocating independent network transmission channels and I / O processing priority permissions, and restricting CPU scheduling weights, I / O bandwidth, and network transmission rates for background tasks that cannot be interrupted. This is equivalent to steps 610 to 620 and step 420 above.

[0066] The transaction protection mode controller is used to control the activation and deactivation of transaction protection mode, and to monitor the liveness status of the transaction process in real time through a transaction session heartbeat mechanism. When an abnormality is detected in the transaction process, the transaction recovery mode is automatically triggered, resource locks are released, and the transaction state is rolled back. This is equivalent to steps 110, 510 to 520 above.

[0067] Please refer to Figure 2 The following details the application embodiments of this application. This application can apply the above solution to scenarios requiring transaction event-driven dynamic resource scheduling and control of POS terminals, especially in resource management where transaction priority must be guaranteed when payment transactions and backend ecosystem tasks are executed concurrently. Taking a large supermarket dual-screen POS terminal payment scenario as an example, the steps include: S1. When a transaction begins, the payment application sends a transaction event process to the system through the transaction interface. For example, when a user initiates a QR code payment at a supermarket dual-screen POS terminal, the payment application sends a transaction start event to the system through the transaction interface. This transaction event process includes transaction status change information. This is equivalent to step 110 above.

[0068] S2. The transaction event process is transmitted to the Transaction Resource Manager Service (TRM) unified resource scheduler, which then controls the activation of the transaction protection mode. For example, after the TRM listens for the transaction event process sent by the transaction application through the transaction interface or system event distribution mechanism, it controls the electronic device to activate the transaction protection mode, prioritizing system resources for the transaction process. Simultaneously, the TRM continuously monitors the liveness status of the transaction process through a transaction session heartbeat mechanism, automatically triggering the transaction recovery mode when an abnormality is detected. This is equivalent to steps 210 and 220, and steps 230 to 270 above.

[0069] S3. The unified resource scheduler obtains the task control block for each background task through the task control block manager. For example, when the unified resource scheduler is in transaction protection mode, it obtains the task control block for each background task through the task control block manager. The task control block manager obtains the creation event of each background task through the process management mechanism, retrieves the identification information of the background task from the creation event, and generates or matches the corresponding task control block based on the identification information of the background task. The task control block is used to uniformly manage the lifecycle and scheduling information of background tasks, and includes at least the task interruption attribute used to identify the background task. This is equivalent to steps 120, 310, and 320 above.

[0070] S4. The Task Control Block Manager associates the task control block with the corresponding resource control group. For example, the Task Control Block Manager associates a task control block with a corresponding resource control group, which is used to constrain the CPU, I / O, and network resource usage of background tasks. This is equivalent to step 330 above.

[0071] S5. The resource control group allocates CPU, network, and I / O resources to the transaction process and performs resource control for background tasks. For example, the resource control group sets CPU resource acquisition priority for the transaction process, allocates independent network QoS control and network resource channels, and sets priority permissions for input / output processing. Simultaneously, for background tasks that can be interrupted, the unified resource scheduler switches the background task to a suspended state and saves its execution context; for background tasks that cannot be interrupted, the resource control group restricts the CPU, I / O, and network resource usage levels of the background task. This is equivalent to steps 610 to 630 and steps 410 and 420 above.

[0072] S6. The transaction protection mode controller controls the activation and deactivation of the transaction protection mode, as well as timeout recovery. For example, the transaction protection mode controller activates the transaction protection mode at the start of a transaction and deactivates it at the end of a transaction. When an abnormality is detected in the transaction process, the transaction protection mode controller automatically triggers the transaction recovery mode, switching the system from the transaction protection state to the resource recovery state. This is equivalent to steps 510 and 520 above.

[0073] S7. The installation management service controls application installation operations and controls the system upgrade task control module to restrict OTA upgrade partition switching operations. For example, the unified resource scheduler controls and restricts the execution of application installation operations through the installation management service and restricts the execution of system restart operations and upgrade partition switching operations through the system upgrade task control module. This is equivalent to step 630 above.

[0074] S8. The system upgrade task control module performs differentiated resource control based on the execution stage of the system upgrade task. For example, the system upgrade task control module obtains the current execution stage of the system upgrade task. If the execution stage is the download stage or the verification stage, the execution of the system upgrade task is paused or the resource consumption level of the system upgrade task is limited; if the execution stage is the partition write stage or the partition switch stage, the continuous execution of the system upgrade task is maintained, and the resource consumption of the system upgrade task is limited; if the execution stage is the restart stage, and an ongoing transaction event is detected, the system restart operation is delayed. This is equivalent to steps 710 to 740 above.

[0075] Through the above application embodiments, the present invention effectively solves the problems in related technologies, such as the inability to safely resume critical tasks due to simply pausing background tasks, lack of awareness of the interruption attributes and execution stages of background tasks, inability to distinguish recovery after the transaction ends, and low resource utilization. It realizes a substantial leap from mutual conflict to collaborative coexistence between transaction business and background tasks, and provides a standardized scheduling scheme with high real-time performance, high reliability, and high resource utilization for payment terminals.

[0076] Please refer to Figure 3 The main process of the transaction protection model in this application is described in detail below. Figure 3 yes Figure 2 The document describes the steps involved in the process, including the activation of the S2 unified resource scheduler control transaction protection mode, the S4 differentiated resource scheduling control, and the S5 resource allocation. It outlines the complete decision-making and execution process from transaction event monitoring to task recovery after the transaction ends, encompassing the following steps: S101. The electronic device monitors the transaction event progress sent by the transaction application in real time through the transaction service interface or the system event distribution mechanism. When the transaction application initiates a payment transaction, it sends the transaction event progress to the system through the transaction service interface. The system then transmits this transaction event progress to the resource scheduling module through the system event distribution mechanism, and the resource scheduling module detects the arrival of the transaction event progress. The electronic device judges the monitored transaction event progress. If the current transaction event progress is a transaction start event, it continues execution; if the current transaction event progress is another transaction status change event or a transaction start event has not yet been detected, it continues to monitor until the transaction start event arrives.

[0077] When a transaction start event is detected, the resource scheduling module controls the electronic device to activate transaction protection mode. In transaction protection mode, system resources are prioritized for the transaction process, providing a prioritized execution environment for payment transactions to ensure the real-time performance and stability of the transaction process. Simultaneously, the transaction protection mode controller begins monitoring the liveness status of the transaction process. This is equivalent to step 110 above.

[0078] S102. With transaction protection mode enabled, the unified resource scheduler scans the task control block list of all background tasks in the current system through the task control block manager, obtains the task control block for each background task, reads the task interruption attribute from the task control block, and classifies and identifies each background task according to the task interruption attribute. This is equivalent to step 120 above.

[0079] S103. The unified resource scheduler determines whether each background task is allowed to be interrupted based on the task interruption attribute in the task control block. If the task interruption attribute indicates that the background task is allowed to be interrupted, then S24 is executed; if the task interruption attribute indicates that the background task is not allowed to be interrupted, then S25 is executed.

[0080] S104. When the task interruption attribute indicates that the background task is allowed to be interrupted, the unified resource scheduler switches the task status of the background task to the suspended state, saves the execution context of the background task to the storage area, and the execution context includes the current execution progress, breakpoint position and intermediate data of the background task. At the same time, it saves the breakpoint position of the background task as a checkpoint so that execution can be resumed from the breakpoint later. This is equivalent to step 410 above.

[0081] S105. When the task interruption attribute indicates that the background task is not allowed to be interrupted, the unified resource scheduler does not suspend the background task. Instead, it restricts the resource usage level of the background task through the resource control group. Specifically, this includes limiting the CPU scheduling weight of the background task, limiting the input / output bandwidth, and limiting the network transmission rate. This allows the background task to continue running in a deloaded manner in transaction protection mode, reducing resource preemption on the transaction process. This is equivalent to step 420 above.

[0082] S106. For background tasks that are allowed to be interrupted, the task control block manager records the current execution progress and breakpoint position of the background task in the task control block so that execution can be resumed from the breakpoint after the transaction ends.

[0083] For background tasks that cannot be interrupted, the resource control group limits the CPU scheduling weight, I / O bandwidth, and network transmission rate of the background task through the resource control unit, thereby reducing its consumption of system resources while ensuring the continuous execution of the background task. This is equivalent to step 420 above.

[0084] S107. The unified resource scheduler sets a higher priority for transaction processes to acquire CPU resources than background tasks through the resource control group, and allocates independent network transmission channels and input / output processing priority permissions to ensure that transaction processes can obtain CPU, network, and input / output resources first. This is equivalent to steps 610 to 620 above.

[0085] S108. The unified resource scheduler controls and restricts the execution of application installation operations through the installation management service, and restricts the execution of system restart operations and upgrade partition switching operations through the system upgrade task control module, thereby avoiding interference of system-level critical operations with the transaction process. This is equivalent to step 630 above.

[0086] S109. The electronic device continuously monitors the transaction event process and determines whether the transaction event process has ended. If the transaction event process has not ended, the electronic device keeps the transaction protection mode enabled and continues to execute the resource scheduling control process from S23 to S29 to continuously ensure the resource requirements of the transaction process until the transaction event process ends.

[0087] When the transaction event process is detected to have ended, the transaction protection mode controller controls the electronic device to exit the transaction protection mode, ending the transaction protection state, and system resources are no longer allocated to the transaction process. This is equivalent to step 110.

[0088] S110. For a suspended background task, the task control block manager reads the task control block of the suspended background task, resumes the execution of the background task according to the execution context and checkpoint saved in the task control block, and adds the background task back to the task scheduling queue, so that the background task can continue execution from the breakpoint when it was suspended. This is equivalent to step 510 above.

[0089] S111. For background tasks whose resource usage levels are restricted, the resource control group removes the restrictions on the resource usage levels of the background tasks, restores the CPU scheduling weight, I / O bandwidth, and network transmission rate of the background tasks, and allows the background tasks to resume normal execution. This is equivalent to step 520 above.

[0090] S112. If there is a pending system upgrade restart operation before the transaction begins, and the system upgrade task control module has delayed this restart operation when the transaction protection mode is enabled, after exiting the transaction protection mode, the system upgrade task control module checks whether there is a pending restart operation. If so, it executes the system restart operation to complete the system upgrade. This is equivalent to step 740 above.

[0091] Through the above process, this application realizes a closed loop of the entire process from transaction event monitoring, transaction protection mode activation, differentiated scheduling of background tasks, resource allocation, continuation of transaction protection mode, to task recovery after the transaction ends, effectively ensuring the priority execution of the transaction process, while also taking into account the execution needs of background tasks.

[0092] Please refer to Figure 4 The following section details the lifecycle management process of the task control block in this application. Figure 4 Yes Figure 2 The S3 unified resource scheduler obtains further expansions of the task control block for each background task through the task control block manager. It describes the task control block as a data structure that abstracts and encapsulates each background task, used to uniformly manage the complete lifecycle and scheduling information of a task from creation to completion. Taking a background data synchronization task as an example, it includes the following steps: S201, Initialization state: When the electronic device detects that a background task has been created through the process management mechanism, the task control block manager generates a corresponding task control block for the background task. At this time, the state of the task control block is the initialization state, which means that the task control block has been established but has not yet been added to the scheduling queue.

[0093] S202, Waiting for scheduling state: The task control block manager adds the task control block in the initialization state to the task scheduling queue. The state of the task control block is switched to the waiting for scheduling state, indicating that the background task is ready and waiting for the unified resource scheduler to allocate resources before execution.

[0094] S203, Running Status: When the unified resource scheduler allocates system resources to the background task, the background task begins execution, and the status of its task control block switches to the running status, indicating that the background task is running normally.

[0095] S204 Suspended State: When transaction protection mode is enabled, for background tasks whose interruption attribute is marked as allowed to be interrupted, the unified resource scheduler switches the task state of the background task to the suspended state, suspends the execution of the background task, and saves the execution context of the background task to the storage area.

[0096] S205. Transaction End Resumption: When the transaction event process is detected to have ended, the suspended background task is resumed from the suspended state to the running state. The task control block manager reads the task control block of the suspended background task, resumes the execution of the background task according to the execution context saved in the task control block, and adds the background task back to the task scheduling queue.

[0097] S206. Restricted running state: When transaction protection mode is enabled, for background tasks whose interrupt attributes are marked as not allowed to be interrupted, the unified resource scheduler restricts the CPU scheduling weight, input / output bandwidth and network transmission rate of the background task through the resource control group. The task status of the background task is switched to restricted running state, and it continues to run in deload mode.

[0098] S207 Failure State: When an exception occurs during the execution of a background task, the state of the task control block of that background task switches to the failure state, indicating that the background task has failed to execute.

[0099] Through the above process, differentiated lifecycle management is achieved for different types of background tasks by using task interruption attributes. Tasks that are allowed to be interrupted enter a suspended state when a transaction occurs and resume execution after the transaction ends, while tasks that are not allowed to be interrupted enter a restricted running state when a transaction occurs. This enables fine-grained control over the lifecycle of background tasks.

[0100] Please refer to Figure 5 The following section details the system upgrade task phase control process of this application. Figure 5 Yes Figure 2The S8 system upgrade task control module further elaborates on the differentiated resource control based on the execution stage of the system upgrade, describing differentiated resource control strategies for different execution stages of the system upgrade task. System upgrade tasks (and OTA upgrade tasks) have different tolerance levels for terminals at different execution stages. This application implements differentiated resource control strategies based on the execution stage of the system upgrade task. This includes the following steps: S301. When the electronic device receives a system upgrade command, the system upgrade task control module starts the system upgrade task and obtains the current execution stage of the system upgrade task. The execution stage of the system upgrade task includes at least one of the following: download stage, verification stage, partition writing stage, slot switching stage, and restart taking effect stage. This is equivalent to step 710 above.

[0101] S302. If the current stage is the download stage or the verification stage, then pause the execution of the system upgrade task or limit the resource usage level of the system upgrade task. The download stage and the verification stage are interruptible stages; after pausing or limiting the speed, execution can be resumed from the breakpoint without affecting the final completion of the system upgrade task. This is equivalent to step 720 above.

[0102] S303. If the current stage is a partition write stage or a slot switching stage, maintain the continuous execution of the system upgrade task and limit the CPU scheduling weight and I / O bandwidth of the system upgrade task. The partition write stage and the slot switching stage are uninterruptible stages, and it is necessary to ensure that critical operations are not interrupted while minimizing the impact on the transaction process. This is equivalent to step 730 above.

[0103] S304. If the current stage is the restart activation stage, check if there are any ongoing transaction events. If there are ongoing transaction events, delay the system restart operation until the transaction event process is completed; if there are no ongoing transaction events, immediately execute the system restart operation to complete the system upgrade. This is equivalent to step 740 above.

[0104] Through the above process, this invention adopts differentiated resource control strategies according to the different execution stages of the system upgrade task: during the download and verification stages, pause or rate limiting is allowed to release resources for the transaction process; during the partition writing and slot switching stages, interruption is prohibited and CPU and I / O are limited to ensure that critical operations are not interrupted while reducing the impact on the transaction process; during the restart effect stage, the restart is delayed or executed immediately depending on whether there is a transaction event to avoid interruption of the transaction process, thus realizing the collaborative coexistence of system upgrade tasks and transaction business.

[0105] Please refer to Figure 6 The OS-level resource mapping mechanism of this application is described in detail below. It includes the following steps: S401, Task Control Block: The unified resource scheduler establishes a corresponding task control block for each background task through the task control block manager. The task control block is used to uniformly manage the lifecycle and scheduling information of background tasks, including at least task interruption attributes, CPU resource quotas, network bandwidth quotas, and I / O resource quotas. The task control block communicates with the Framework system service through Binder IPC to pass the scheduling policy to the system resource control layer. This is equivalent to steps 120 and 310 to 320 above.

[0106] S402, cgroup task groups: The Task Control Block Manager binds task control blocks to cgroup task groups. Cgroup task groups are a resource control mechanism provided by the operating system kernel, used to restrict and isolate resource usage by processes or thread groups. Each background task corresponds to an independent cgroup task group, thereby achieving task-level resource governance. This is equivalent to step 330 above.

[0107] S403, cpu.cfs_quota_us: The unified resource scheduler dynamically adjusts the CPU resource quota for background tasks through the cpu.cfs_quota_us interface in the cgroup task group, including setting CPU bandwidth limits and scheduling priorities, to ensure that the transaction process can obtain CPU resources first in transaction protection mode. This is equivalent to step 610 above.

[0108] S404, blkio / io.max: The unified resource scheduler limits the disk I / O resources of background tasks through the blkio / io.max interface in the cgroup task group, including limiting disk read / write bandwidth and I / O operation frequency, to prevent background task I / O operations from affecting the response speed of the transaction process. This is equivalent to steps 420 and 620 above.

[0109] S405, tc / net_cls: The unified resource scheduler limits the network bandwidth of background tasks through the tc / net_cls interface in the cgroup task group, including setting network transmission rate limits and network QoS policies, to prevent the network traffic of background tasks from affecting the communication quality of the transaction process. This is equivalent to steps 420 and 620 above.

[0110] S406, Binder IPC, and Framework system services: The unified resource scheduler communicates with the Framework system services through the Binder IPC inter-process communication mechanism, passing resource scheduling instructions to the system service layer, whereby the Framework system services execute specific resource control operations.

[0111] S407, PMS control and OTA control: The unified resource scheduler uses PMS (Installation Management Service) to intercept and restrict application installation operations, pausing or delaying them in transaction protection mode; it uses OTA to control the execution of system upgrade tasks, restricting system restart operations and upgrade partition switching operations, and resuming OTA task execution after the transaction ends. This is equivalent to steps 630 and 710 to 740 above.

[0112] Through the above mechanism, this application maps the application layer scheduling policy to the operating system resource control layer by binding the task control block with the cgroup task group, thereby achieving unified isolation and dynamic scheduling of CPU, IO and network resources of background tasks; through PMS control and OTA control, the control scope is extended to system-level critical behaviors, realizing comprehensive control over application installation and system upgrades under the transaction protection mode, and providing comprehensive resource protection for the transaction process.

[0113] Please refer to Figure 7 The following section details the transaction resource preemption and timing control process of this application. Figure 7 Yes Figure 2 Further details of the complete timing sequence from S1 to S6 include the following steps: S501. The payment application calls the `notifyTransactionStart()` method of the transaction interface to send a transaction start event to the system. For example, when a user initiates a payment at a POS terminal, the payment application calls the notification method of the transaction interface to send a transaction start event to the system. This event is used to trigger the activation of transaction protection mode. The system transmits the transaction start event to the unified resource scheduler through the Binder IPC inter-process communication mechanism. After receiving the transaction start event, the unified resource scheduler controls the electronic device to enter transaction protection mode, and system resources begin to be allocated to the transaction process. This is equivalent to step 110 above.

[0114] S502. The Unified Resource Scheduler scans the task control block list to obtain the task control block for each background task. For example, the Unified Resource Scheduler scans the task control block list of all background tasks in the current system through the task control block manager and reads the task interruption attribute from each task control block. This is equivalent to steps 120, 310, and 320 above.

[0115] S503. The unified resource scheduler checks the execution phase of background tasks to determine whether the task is in an uninterruptible phase. For example, for a system upgrade task, the unified resource scheduler obtains the current execution phase of the system upgrade task and determines whether the phase is uninterruptible, such as the partition writing phase or the slot switching phase. This is equivalent to step 710 above.

[0116] S504. For tasks that are allowed to be interrupted, the unified resource scheduler switches the task state to a suspended state and saves the execution context. For example, for a background task whose interruption attribute is marked as allowed to be interrupted, the unified resource scheduler suspends the task, pauses its execution, and saves the current execution progress. This is equivalent to step 410 above.

[0117] S505. For tasks in the uninterruptible phase, the unified resource scheduler reduces the CPU scheduling weight and I / O quota of background tasks through resource control groups. For example, for system upgrade tasks in the partition write phase, the unified resource scheduler limits their CPU and I / O resource usage, ensuring continuous task execution while reducing the impact on the transaction process. This is equivalent to steps 420 and 730 above.

[0118] S506. The unified resource scheduler elevates the thread priority of the transaction process. For example, the unified resource scheduler uses resource control groups to set a higher processor resource acquisition priority for the transaction process than for background tasks, ensuring that the transaction process has priority in obtaining system resources. This is equivalent to step 610 above.

[0119] S507. The unified resource scheduler prohibits system restart operations. For example, the unified resource scheduler restricts the execution of system restart operations through the system upgrade task control module to prevent transaction interruption caused by system restart during the transaction process. This is equivalent to step 630 above.

[0120] S508. The payment application calls the "Notify Transaction End" method through the transaction interface to send a transaction end event to the system. For example, after a transaction is completed, the payment application calls the notification method of the transaction interface to send a transaction end event to the system. The unified resource scheduler receives the transaction end event, prepares to execute the transaction protection mode exit process, and resumes the execution of suspended tasks. For example, the unified resource scheduler reads the task control block of the suspended background task, resumes the execution of the background task according to the execution context saved in the task control block, and re-adds the background task to the task scheduling queue. This is equivalent to step 510 above.

[0121] S509. The unified resource scheduler performs a delayed restart operation. For example, if there is a pending system upgrade restart operation before the transaction begins, the unified resource scheduler performs the system restart operation after the transaction ends to complete the system upgrade. This is equivalent to step 740 above.

[0122] Through the above-described timing process, this invention achieves full-link resource preemption and timing control from the start of a transaction initiated by the payment application, through the system entering transaction protection mode, differentiated resource scheduling, transaction completion, exiting transaction protection mode, and resuming background tasks. This ensures that the transaction event process can obtain sufficient system resources during critical periods, while also ensuring that background tasks can be resumed in a timely manner after the transaction ends.

[0123] Please refer to Figure 8 The following section details the transaction timeout protection and anomaly recovery process of this application. Figure 8 Yes Figure 2 The further development of the transaction timeout protection mechanism included in the transaction protection mode controlled by the S2 unified resource scheduler includes the following steps: S601. The payment application initiates a transaction through the transaction interface and sends a transaction start event to the system. The unified resource scheduler controls the electronic device to start the transaction protection mode. The system enters the transaction protection state, and resources begin to be allocated to the transaction event process.

[0124] S602. In transaction protection mode, the unified resource scheduler locks system resources, including setting processor resource acquisition priority for the transaction process, allocating independent network transmission channels and input / output processing priority permissions, while freezing application installation operations and OTA partition switching operations to ensure that the transaction process can exclusively occupy sufficient system resources.

[0125] S603: Electronic devices continuously monitor the execution status of the transaction process, the transaction protection mode remains enabled, the unified resource scheduler continuously provides resource guarantees for the transaction process, and the background tasks remain suspended or unloaded based on the task interruption attributes.

[0126] S604. The transaction protection mode controller continuously monitors the survival status of the transaction process through the transaction session heartbeat mechanism to determine whether the transaction process is running normally. If the heartbeat is normal, the transaction continues normally and returns to S603; if the heartbeat times out or is abnormal, S605 is executed.

[0127] S605. When the transaction session heartbeat times out or an abnormality is detected in the transaction process (such as application crash, communication link disconnection, etc.), the transaction protection mode controller determines that the transaction process has become abnormal and triggers the transaction recovery mode.

[0128] S606, The transaction protection mode controller controls the electronic device to switch from the transaction protection state to the transaction recovery mode, and begins to execute the system resource and transaction state recovery process.

[0129] S607, The unified resource scheduler releases system resources occupied in the transaction protection mode, including reclaiming processor resources of the transaction process to obtain priority, releasing independent network transmission channels and input / output processing priority permissions, so that system resources are restored to the normal allocation state before the transaction.

[0130] S608, the transaction protection mode controller marks the current transaction session status as terminated, indicating that the transaction session is considered invalid and terminated at the system level, but does not make any success or failure judgment on the transaction result. The transaction result is completed independently by the payment application and its back-end system.

[0131] S609. The unified resource scheduler restores the system to its normal scheduling state, including resuming the execution of suspended background tasks, removing resource load reduction restrictions on background tasks, and resuming the execution of application installation operations and OTA partition switching operations, so that the system returns to its normal resource scheduling state.

[0132] Through the above process, this application monitors the survival status of the transaction process in real time through the transaction session heartbeat mechanism. When an abnormality in the transaction process is detected, the transaction recovery mode is automatically triggered, the system resources locked in the transaction protection mode are released in a timely manner, and the transaction status is rolled back. This avoids the problem that the system is in a state of resource suppression for a long time, which causes the background tasks to be unable to run normally. At the same time, the transaction business results are not judged, ensuring that the transaction results are completed independently by the payment application and its backend system, thus ensuring the stability and reliability of the system.

[0133] Please refer to Figure 9 The present invention also provides an electronic device 900, including a memory 901 and a processor 902, and a computer program stored on the memory 901 and running on the processor 902. When the processor 902 executes the computer program, it implements the various steps in the resource scheduling method based on transaction events as described above.

[0134] The beneficial effects of the electronic device of the present invention are the same as those of the method described above, and will not be repeated here.

[0135] In summary, this invention constructs a resource scheduling method and electronic device based on transaction events.

[0136] During transaction event processing, the system monitors the transaction event progress in real time through the transaction service interface and system event distribution mechanism, continuously monitoring the survival status of the transaction process. When an anomaly is detected, the transaction recovery mode is automatically triggered. Once the transaction protection mode is enabled, the unified resource scheduler establishes a corresponding task control block for each background task through the task control block manager. Each task control block includes at least a task interruption attribute to identify whether a background task is allowed to be interrupted, and the task control block is bound to a resource control group. Based on the task interruption attribute, background tasks that are allowed to be interrupted are suspended and their execution context is saved. For background tasks that are not allowed to be interrupted, CPU, I / O, and network resource usage is restricted through the resource control group. Simultaneously, the unified resource scheduler sets processor resource acquisition priorities for the transaction process, allocates independent network transmission channels and I / O processing priority permissions, and restricts system-level critical operations such as system restarts, application installations, and upgrade partition switching to ensure the resource needs of the transaction process are met. This method differs from related technologies that simply pause all background tasks or statically restrict task execution. Through unified management of task interruption attributes and differentiated resource scheduling strategies, it overcomes the deficiency of being unable to safely recover after a critical task is forcibly interrupted.

[0137] Furthermore, the system establishes a resource fairness control mechanism based on the duration of the transaction protection mode. When the transaction protection mode lasts too long, it automatically reduces the resource consumption level of the transaction process, allowing background tasks to execute intermittently and preventing resource starvation or system-wide crashes caused by prolonged suppression of background tasks. When the transaction event process ends, the unified resource scheduler exits the transaction protection mode, resumes the execution of suspended tasks, removes resource restrictions on background tasks, and performs a delayed system upgrade and restart operation. This method is suitable for resource scheduling in scenarios where payment terminals execute transactions and background ecosystem tasks concurrently, solving the problems of poor scheduling flexibility, inability to safely resume critical tasks, low execution efficiency of background tasks, and insufficient resource utilization in related technologies.

[0138] The above are merely embodiments of the present invention and do not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention's specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for resource scheduling based on transaction events, characterized in that, Applied to electronic devices, the method includes: When a transaction event process is detected, the transaction protection mode is activated, and the transaction event process includes the transaction status change process. When the transaction protection mode is enabled, obtain the task control block for each background task. The task control block includes at least a task interruption attribute for identifying the background task. Based on the task interruption attribute, resource scheduling control is performed on each background task to ensure the smooth progress of the transaction event.

2. The method of claim 1, wherein, The step of controlling the activation of the transaction protection mode when a transaction event process is detected includes: The process of monitoring the transaction events sent by the transaction application is carried out through the transaction service interface; Alternatively, the transaction event process transmitted by the system to the resource scheduling module can be obtained through the system event distribution mechanism.

3. The method of claim 2, wherein, Also includes: When the transaction event process sent by the transaction application is detected through the transaction service interface, the trustworthiness of the transaction application is verified. If the trustworthiness verification fails, the transaction application is prohibited from triggering the transaction protection mode; If the trustworthiness verification passes, a unique transaction session identifier is generated for the transaction event process sent by the transaction application, and the state continuity of the transaction event process is verified. If the state continuity check fails, the transaction application is prohibited from triggering the transaction protection mode. If the state continuity verification passes, the transaction application is allowed to trigger the transaction protection mode.

4. The method of claim 1, wherein, The step of obtaining the task control block for each background task when the transaction protection mode is enabled includes: The creation event of each background task is obtained through the process management mechanism, and the identification information of the background task is obtained from the creation event. The task control block is generated or matched based on the identification information of the background task; The task control block is associated with a corresponding resource control unit, which is used to constrain the resource usage of the background task.

5. The method of claim 1, wherein, The step of performing resource scheduling control on each background task based on the task interruption attribute includes: When the task interruption attribute indicates that the background task is allowed to be interrupted, the task status of the background task is switched to the suspended state, and the execution context of the background task is saved. When the task interruption attribute indicates that the background task is not allowed to be interrupted, the resource usage level of the background task is limited.

6. The method of claim 5, wherein, The task control block includes at least a task interruption attribute for identifying the background task. The step of obtaining the task control block for each background task when the transaction protection mode is enabled includes: When the task interruption attribute indicates that the background task is allowed to be interrupted, the task control block of the suspended background task is read, the execution of the background task is resumed according to the execution context of the background task stored in the task control block, and the background task is added back to the task scheduling queue. When the task interruption attribute indicates that the background task is not allowed to be interrupted, the restriction on the resource usage level of the background task is lifted.

7. The method of claim 1, wherein, The step of acquiring the task control block for each background task while the transaction protection mode is enabled further includes: Set the processor resource acquisition priority for the transaction process; Allocate independent network transmission channels and input / output processing priority permissions to the transaction process; Restrict the execution of system restart operations, application security operations, and system upgrade partition switching operations.

8. The method of claim 1, wherein, The step of performing resource scheduling control on each background task based on the task interruption attribute further includes: When the background task is a system upgrade task, obtain the current execution stage of the system upgrade task; If the execution phase is a download phase or a verification phase, then the execution of the system upgrade task is paused or the resource consumption level of the system upgrade task is limited. If the execution phase is a partition writing phase or a partition switching phase, the continuous execution of the system upgrade task is maintained, and the resource consumption of the system upgrade task is limited. If the execution phase is a restart phase, and an ongoing transaction event is detected, the system restart operation will be delayed.

9. The resource scheduling method based on transaction events according to claim 1, characterized in that, Also includes: Monitor the duration of the transaction protection mode; When the duration exceeds a preset threshold, the resource consumption level of the transaction event is limited, and the suspended background task is allowed to execute intermittently.

10. An electronic device, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor, when executing the computer program, implements a resource scheduling method based on transaction events as described in any one of claims 1 to 9.

Images