Asynchronous operation execution method and related device

Abstract

Embodiments of the present application provide an asynchronous operation execution method and related devices. The asynchronous operation execution method comprises: in response to an asynchronous operation call, calling an application level state management interface; if a lock value is stored in the application level state management interface, then detecting the application level state management interface every predetermined time until the application level state management interface does not store a lock value; if the application level state management interface does not store a lock value, then storing a lock value in the application level state management interface and executing the asynchronous operation; and in response to the asynchronous operation being executed, releasing the lock value in the application level state management interface. The technical solution of the embodiments of the present application identifies whether a lock is occupied by storing a lock value in an application level state management interface AppStorage, implements a lock mechanism, ensures that only one operation can access a shared resource when multiple asynchronous operations are executed, and avoids concurrent conflicts.

Description

Technical Field

[0001] This application relates to the fields of computer and communication technology, and more specifically, to an asynchronous operation execution method and related equipment. Background Technology

[0002] ArkTS is the preferred application development language for HarmonyOS, supporting standard JavaScript asynchronous concurrency capabilities such as Promises and async / await. When concurrently calling the same async method within the same thread, data synchronization needs to be considered, requiring the use of mutex locks to ensure data synchronization. However, since HarmonyOS does not provide a mutex lock API, ensuring data synchronization is difficult. Summary of the Invention

[0003] The embodiments of this application provide an asynchronous operation execution method and related equipment, which can at least to some extent overcome the problem that HarmonyOS does not have a mutex lock API.

[0004] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0005] According to one aspect of the embodiments of this application, an asynchronous operation execution method is provided, comprising: in response to the invocation of an asynchronous operation, invoking an application-level state management interface; detecting whether a lock value is stored in the application-level state management interface; when it is detected that no lock value is stored in the application-level state management interface, storing a lock value in the application-level state management interface and executing the asynchronous operation; and releasing the lock value in the application-level state management interface in response to the completion of the asynchronous operation.

[0006] In some feasible embodiments of this application, the method further includes: when a lock value is detected stored in the application-level state management interface, checking the application-level state management interface once every predetermined time period until the application-level state management interface does not store a lock value.

[0007] In some feasible embodiments of this application, there are multiple lock values, each corresponding to a different group of asynchronous operations; the step of detecting that the application-level state management interface stores a lock value, checking the application-level state management interface every predetermined time interval until the application-level state management interface no longer stores a lock value, specifically includes: when the application-level state management interface stores a lock value corresponding to the asynchronous operation, checking the application-level state management interface every predetermined time interval until the application-level state management interface no longer stores the corresponding lock value; the step of storing a lock value in the application-level state management interface and executing the asynchronous operation when no lock value is detected in the application-level state management interface, specifically includes: when the application-level state management interface does not store a lock value corresponding to the asynchronous operation, storing the corresponding lock value in the application-level state management interface and executing the asynchronous operation.

[0008] In some feasible embodiments of this application, the step of detecting the application-level state management interface every predetermined time interval when a lock value is detected in the application-level state management interface until the application-level state management interface no longer stores a lock value specifically includes: starting a timer when a lock value is detected in the application-level state management interface; and detecting the application-level state management interface every predetermined time interval until the application-level state management interface no longer stores a lock value or the timer exceeds a predetermined timeout threshold.

[0009] In some feasible embodiments of this application, the asynchronous operation execution method further includes: automatically triggering a timeout mechanism if the timing exceeds a predetermined timeout threshold.

[0010] In some feasible embodiments of this application, the step of automatically triggering a timeout mechanism if the timeout exceeds a predetermined timeout threshold specifically includes: if the timeout exceeds the predetermined timeout threshold, suspending the current asynchronous operation and marking the current asynchronous operation as failed; and releasing the lock value at the application-level state management interface.

[0011] In some feasible embodiments of this application, each asynchronous operation includes a unique identifier, and the application-level state management interface also stores a unique identifier corresponding to each asynchronous operation that stores a lock value. The step of storing a lock value in the application-level state management interface and executing the asynchronous operation when it is detected that no lock value is stored therein specifically includes: storing a lock value in the application-level state management interface and updating the unique identifier when it is detected that no lock value is stored therein, and executing the asynchronous operation; responding to the detection of the application-level state management interface by the asynchronous operation, determining whether the unique identifier of the asynchronous operation is consistent with the unique identifier in the application-level state management interface; if the unique identifier of the asynchronous operation is consistent with the unique identifier in the application-level state management interface, directly returning a state of successful lock value storage and updating the re-entry count.

[0012] In some feasible embodiments of this application, the step of releasing the lock value at the application-level state management interface in response to the completion of the asynchronous operation specifically includes: in response to the completion of the asynchronous operation, determining whether the reentry count has returned to zero; if the reentry count has not returned to zero, decreasing the value of the reentry count until the reentry count returns to zero; if the reentry count has returned to zero, releasing the lock value at the application-level state management interface.

[0013] According to one aspect of the embodiments of this application, an asynchronous operation execution device is provided, the asynchronous operation execution device comprising: an interface calling module, configured to call an application-level state management interface in response to an asynchronous operation call; a lock detection module, configured to detect whether a lock value is stored in the application-level state management interface; an operation execution module, configured to store a lock value in the application-level state management interface and execute the asynchronous operation when it is detected that no lock value is stored in the application-level state management interface; and a lock release module, configured to release the lock value in the application-level state management interface in response to the completion of the asynchronous operation.

[0014] In some feasible embodiments of this application, the apparatus further includes: a loop detection module, configured to detect the application-level state management interface once every predetermined time period when a lock value is detected stored in the application-level state management interface, until the application-level state management interface no longer stores a lock value.

[0015] In some feasible embodiments of this application, there are multiple lock values, each corresponding to a different group of asynchronous operations; the loop detection module is specifically used to perform the following: when it is detected that the application-level state management interface stores a lock value corresponding to the asynchronous operation, the application-level state management interface is checked once every predetermined time until the application-level state management interface does not store the corresponding lock value; the operation execution module is specifically used to perform the following: when it is detected that the application-level state management interface does not store a lock value corresponding to the asynchronous operation, the corresponding lock value is stored in the application-level state management interface, and the asynchronous operation is executed.

[0016] In some feasible embodiments of this application, the loop detection module specifically includes: a timing submodule, used to start timing when a lock value is detected stored in the application-level state management interface; and a detection submodule, used to detect the application-level state management interface once every predetermined time interval until the application-level state management interface no longer stores a lock value or the timing exceeds a predetermined timeout threshold.

[0017] In some feasible embodiments of this application, the asynchronous operation execution device further includes: a timeout mechanism module, used to automatically trigger the timeout mechanism if the timing exceeds a predetermined timeout threshold.

[0018] In some feasible embodiments of this application, the timeout mechanism module specifically includes: a stop submodule, used to stop the current asynchronous operation and mark the current asynchronous operation as failed if the timeout exceeds a predetermined timeout threshold; and a release submodule, used to release the lock value at the application-level state management interface.

[0019] In some feasible embodiments of this application, each asynchronous operation includes a unique identifier, and the application-level state management interface also stores a unique identifier corresponding to each asynchronous operation that stores a lock value. The operation execution module specifically includes: an operation execution submodule, used to store a lock value in the application-level state management interface and update the unique identifier when it is detected that no lock value is stored in the application-level state management interface, and execute the asynchronous operation; an identifier comparison submodule, used to determine whether the unique identifier of the asynchronous operation is consistent with the unique identifier in the application-level state management interface in response to the detection of the application-level state management interface by the asynchronous operation; and a re-entry count update submodule, used to directly return the state of successful lock value storage and update the re-entry count if the unique identifier of the asynchronous operation is consistent with the unique identifier in the application-level state management interface.

[0020] In some feasible embodiments of this application, the lock release module specifically includes: a zeroing confirmation submodule, used to determine whether the re-entry count has been zeroed in response to the completion of the asynchronous operation; a zeroing execution submodule, used to reduce the value of the re-entry count until the re-entry count is zero if the re-entry count has not been zeroed; and a lock release submodule, used to release the lock value at the application-level state management interface if the re-entry count has been zeroed.

[0021] According to one aspect of the embodiments of this application, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the asynchronous operation execution method as described in the above embodiments.

[0022] According to one aspect of the embodiments of this application, an electronic device is provided, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement the asynchronous operation execution method as described in the above embodiments.

[0023] A computer program product includes one or more computer programs, characterized in that, when the one or more computer programs are executed by one or more processors, they implement the steps of the asynchronous operation execution method as described in the above embodiments.

[0024] In some embodiments of this application, a locking mechanism is implemented by storing lock values ​​in the application-level state management interface AppStorage to identify whether a lock is held. This ensures that only one operation can access shared resources during the execution of multiple asynchronous operations, avoiding concurrency conflicts. When multiple asynchronous operations request access to the same resource, embodiments of this application can reasonably schedule the execution order, avoiding errors or exceptions caused by concurrent execution. Simultaneously, by periodically checking the lock value's status, infinite blocking while waiting for the lock is avoided. This improves the system's response speed and also prevents deadlocks caused by prolonged lock operation.

[0025] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0026] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort. In the drawings:

[0027] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown.

[0028] Figure 2 A flowchart illustrating an asynchronous operation execution method provided in an embodiment of this application is shown.

[0029] Figure 3 It shows according to Figure 2 A flowchart illustrating a specific implementation of step S400 in the asynchronous operation execution method shown in the corresponding embodiment.

[0030] Figure 4 It shows according to Figure 3 A flowchart illustrating a specific implementation of step S500 in the asynchronous operation execution method shown in the corresponding embodiment.

[0031] Figure 5 A schematic diagram of an asynchronous operation execution device provided in an embodiment of this application is shown.

[0032] Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0033] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0034] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0035] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0036] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0037] Figure 1 A schematic diagram of an exemplary system architecture to which the technical solutions of the embodiments of this application can be applied is shown.

[0038] like Figure 1 As shown, the system architecture may include terminal devices (such as...) Figure 1 The device shown includes one or more of a smartphone 101, tablet 102, and portable computer 103 (which could also be a desktop computer, etc.), a network 104, and a server 105. The network 104 serves as a medium for providing a communication link between the terminal device and the server 105. The network 104 can include various connection types, such as wired communication links, wireless communication links, etc.

[0039] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, there can be any number of terminal devices, networks, and servers. For example, server 105 could be a server cluster composed of multiple servers.

[0040] Users can use terminal devices to interact with server 105 via network 104 to receive or send messages, etc. Server 105 can be a server that provides various services. For example, a user can use terminal device 103 (or terminal device 101 or 102) to upload a program containing asynchronous operations to server 105. Server 105 can call the application-level state management interface in response to the asynchronous operation call. If the application-level state management interface stores a lock value, the application-level state management interface is checked every predetermined time until the application-level state management interface no longer stores a lock value. If the application-level state management interface does not store a lock value, a lock value is stored in the application-level state management interface, and the asynchronous operation is executed. In response to the completion of the asynchronous operation, the lock value is released in the application-level state management interface.

[0041] It should be noted that the asynchronous operation execution method provided in this application embodiment is generally executed by server 105, and correspondingly, the asynchronous operation execution device is generally disposed in server 105. However, in other embodiments of this application, the terminal device may also have similar functions to the server, thereby executing the asynchronous operation execution scheme provided in this application embodiment.

[0042] The implementation details of the technical solutions in the embodiments of this application are described in detail below:

[0043] Figure 2 A flowchart of an asynchronous operation execution method according to an embodiment of this application is shown. This asynchronous operation execution method can be executed by a server, which may be... Figure 1 The server shown. (Refer to...) Figure 2 As shown, the asynchronous operation execution method includes at least the following:

[0044] S100, in response to asynchronous operation calls, invokes the application-level state management interface.

[0045] S200, Detect whether a lock value is stored in the application-level state management interface.

[0046] S300, when it is detected that a lock value is stored in the application-level state management interface, the application-level state management interface is checked once every predetermined time until the application-level state management interface does not store a lock value.

[0047] S400: When it is detected that no lock value is stored in the application-level state management interface, a lock value is stored in the application-level state management interface, and the asynchronous operation is executed.

[0048] S500, in response to the completion of the asynchronous operation, the lock value is released at the application-level state management interface.

[0049] In this embodiment, a locking mechanism is implemented by storing lock values ​​in the application-level state management interface AppStorage to identify whether a lock is held. This ensures that only one operation can access shared resources at a time during the execution of multiple asynchronous operations, avoiding concurrency conflicts. When multiple asynchronous operations request access to the same resource, this embodiment can reasonably schedule the execution order, avoiding errors or exceptions caused by concurrent execution. Simultaneously, by periodically checking the lock value's status, infinite blocking while waiting for the lock is avoided. This improves the system's response speed and also prevents deadlocks caused by prolonged lock operation.

[0050] In S100, when an asynchronous operation is triggered, a response is needed to initiate the execution flow of the asynchronous operation. At this point, an application-level state management interface, AppStorage, must first be called. This interface manages and stores lock values, which indicate whether other asynchronous operations are currently accessing shared resources. In other words, the application-level state management interface centrally manages locks.

[0051] In S200, the system checks whether a lock value is stored in the application-level state management interface AppStorage to determine if any other asynchronous operations are currently accessing the shared resource. If no lock value is detected, it means that no other asynchronous operations are accessing the shared resource; if a lock value is detected, it means that other asynchronous operations are accessing the shared resource.

[0052] In S300, if a lock value is stored in the current state management interface (meaning an operation is in progress), it indicates that the shared resource is occupied and requires waiting. In this case, a predetermined time interval is set to repeatedly check the lock's state until the lock value is released, at which point the shared resource becomes available. This timed checking prevents the program from blocking and waiting indefinitely while the lock value remains unreleased, thus reducing system responsiveness. By using timed checking, the system can continue executing other tasks within a reasonable timeframe, avoiding performance bottlenecks caused by prolonged waiting.

[0053] Specifically, in some embodiments, the specific implementation of step S300 can be found in the following embodiments. This embodiment is based on... Figure 2 According to the detailed description of step S300 in the asynchronous operation execution method shown in the corresponding embodiment, step S300 in the asynchronous operation execution method may include the following steps:

[0054] The timer starts when a lock value is detected stored in the application-level state management interface.

[0055] The application-level state management interface is checked once at predetermined intervals until the application-level state management interface no longer stores a lock value or the timeout exceeds a predetermined timeout threshold.

[0056] In this embodiment, under high concurrency scenarios, multiple asynchronous operations may compete for the same resources. Traditional locking mechanisms often cause some asynchronous operations to be blocked due to excessively long resource waiting times, affecting system response time and overall performance. This embodiment introduces a timed detection scheme by checking at predetermined intervals, ensuring that waiting asynchronous operations are not blocked for extended periods, thus improving system response speed and efficiency. When a lock is held, in addition to periodically checking the lock status, a timeout mechanism of "timeout exceeding a predetermined threshold" is used to prevent deadlocks or system efficiency degradation caused by some asynchronous operations being unable to acquire the lock for an extended period.

[0057] Through the aforementioned periodic checks and timeout mechanisms, the system can avoid getting stuck in a pointless waiting state when the lock is occupied for a long time. Instead, it can abandon the current lock waiting after the timeout and try other available resources or operations, thereby improving the system's resource utilization.

[0058] In this embodiment, if the lock value in the application-level state management interface is not released within the predetermined time range, the system will determine whether the maximum waiting time has been exceeded based on the timer's set value. If the timeout occurs, the system will take appropriate measures, such as stopping the waiting for the current resource, selecting other operations, or notifying the user, to prevent the system from remaining in a waiting state for an extended period. That is, in some embodiments, if the timeout exceeds a predetermined timeout threshold, the timeout mechanism is automatically triggered.

[0059] In this embodiment, a timeout error reporting mechanism enables the system to proactively report exceptions when encountering resource contention or timeout issues, instead of continuing to wait, thus preventing the system from falling into a state of prolonged unresponsiveness and improving the system's robustness.

[0060] In some embodiments, returning detailed error information can provide more accurate exception reports, helping developers quickly locate the problem and thus accelerating the troubleshooting and repair process.

[0061] For users, prolonged periods of unresponsiveness lead to confusion and dissatisfaction. If the system can provide clear feedback immediately after a timeout via an error reporting mechanism, users will understand what happened and can take appropriate action. This design improves the user experience and reduces unnecessary anxiety caused by long wait times.

[0062] In other embodiments, if the timeout exceeds a predetermined timeout threshold, the current asynchronous operation is aborted, the current asynchronous operation is marked as failed, and the lock value is released at the application-level state management interface, effectively preventing deadlock or long-term resource occupation.

[0063] In other embodiments, a timeout callback mechanism can also be used to trigger the corresponding error handling process (e.g., retry, failure rollback, etc.).

[0064] In S400, once a lock value is detected to be empty (i.e., no other operation is occupying the resource), the corresponding asynchronous operation stores the lock value in the application-level state management interface, indicating that the current operation is in progress and other operations cannot access the same resource simultaneously. The target asynchronous operation is then executed. At this point, the operation can be executed, and due to the locking mechanism, other asynchronous operations cannot modify the shared resource simultaneously, ensuring data consistency.

[0065] Specifically, in some embodiments, the specific implementation of step S400 can be found in [reference needed]. Figure 3 . Figure 3 It is based on Figure 2The detailed description of step S400 in the asynchronous operation execution method shown in the corresponding embodiment is as follows: In the asynchronous operation execution method, each asynchronous operation contains a unique identifier, and the application-level state management interface also stores the unique identifier corresponding to each asynchronous operation that stores the lock value. Step S400 may include the following steps:

[0066] S410, when it is detected that no lock value is stored in the application-level state management interface, the lock value is stored in the application-level state management interface and the unique identifier is updated, and the asynchronous operation is executed.

[0067] S420, in response to the detection of the application-level state management interface by the asynchronous operation, determine whether the unique identifier of the asynchronous operation is consistent with the unique identifier in the application-level state management interface.

[0068] S430, if the unique identifier of the asynchronous operation is consistent with the unique identifier in the application-level state management interface, directly return the status of successfully storing the lock value and update the re-entry count.

[0069] When performing asynchronous operations concurrently, multiple attempts to acquire the same lock value may lead to resource contention. Furthermore, if the lock value has already been stored during the execution of an asynchronous operation, the system may mistakenly believe that the lock has already been processed, resulting in redundant operations.

[0070] This embodiment avoids duplicate execution or conflicts of multiple asynchronous operations on the same lock value by assigning a unique identifier to each asynchronous operation and associating the identifier with the lock value's status information, thus ensuring the uniqueness and consistency of the operations. Simultaneously, by storing the unique identifier, the system can also check for duplicate operations, preventing invalid lock value storage and repeated execution.

[0071] In this embodiment, each asynchronous operation has a unique identifier. This identifier helps the system accurately track the state of each operation, avoiding duplicate lock storage or inconsistent operation execution. It ensures that only one operation can successfully store a lock value at any given time, preventing resource contention and conflicts. By determining whether the unique identifiers are consistent, the system can identify asynchronous operations that have successfully stored lock values, avoiding repeated resource locking and operation execution for successfully executed operations, thus improving system efficiency. Using unique identifiers to manage each asynchronous operation also effectively coordinates multiple concurrent asynchronous tasks, preventing them from blocking due to resource contention, and improving the system's processing capacity in high-concurrency environments.

[0072] The application-level state management interface described above not only stores the lock value, but also the unique identifier of each operation, and dynamically updates the reentry count during execution, ensuring that the system's state information is always consistent with the actual operation, thereby improving the system's state tracking capability and troubleshooting efficiency.

[0073] In S410, if no lock value is stored in the application-level state management interface, it means that the resource or task is not yet occupied. The system will store the lock value in the interface and begin executing the asynchronous operation. When the lock value is stored, a unique identifier is simultaneously updated in the state management interface to ensure that subsequent checks on the lock value are based on the correct asynchronous operation identifier. This avoids conflicts or reentrancy issues between different asynchronous operations.

[0074] In S420, when an asynchronous operation completes, the system checks whether the unique identifier stored in the state management interface matches the unique identifier of the operation. If they do not match, it indicates that a lock conflict or operation failure may have occurred, and the system will take appropriate action.

[0075] In S430, if the values ​​match, it means that the operation has been successfully stored in the lock and executed. The system will return a successful operation status and update the reentry count to reflect the execution status of the operation.

[0076] In S500, after an asynchronous operation completes, the lock is released in the application-level state management interface. After the lock is released, other waiting asynchronous operations can begin execution and continue to compete for lock access. Releasing the lock is a critical step. If this step is not executed correctly, other operations will be unable to acquire the lock, and the system will experience deadlock or prolonged blocking.

[0077] Specifically, in some embodiments, the specific implementation of step S500 can be found in [reference needed]. Figure 4 . Figure 4 It is based on Figure 3 According to the detailed description of step S500 in the asynchronous operation execution method shown in the corresponding embodiment, step S500 in the asynchronous operation execution method may include the following steps:

[0078] S510, in response to the completion of the asynchronous operation, determine whether the reentry count has returned to zero.

[0079] S520, if the reentry count is not zero, then decrease the value of the reentry count until the reentry count is zero.

[0080] S530, if the reentry count has reached zero, the lock value is released at the application-level state management interface.

[0081] In this embodiment, by controlling the number of reentrant operations, the lock is ensured to be released only after all relevant asynchronous operations are completed, avoiding concurrency conflicts caused by premature lock release. Simultaneously, by dynamically reducing the number of reentrant operations, the lock is prevented from being repeatedly occupied due to erroneous operations or multiple operations, ensuring the correct release of the lock and improving the system's resource management efficiency and consistency.

[0082] In a high-concurrency environment, this embodiment can ensure the correct execution of asynchronous operations and the release of lock values, avoiding resource waste or unnecessary blocking and improving the system's concurrent processing capabilities.

[0083] In S510, when an asynchronous operation completes, the system checks the reentrancy count. The reentrancy count reflects the number of asynchronous operations associated with the lock, and the system uses this count to determine whether to continue holding the lock or release it. In other words, the reentrancy count determines whether the asynchronous operation has completed. If so, the system continues to check whether all related operations have completed (i.e., whether the reentrancy count has reached zero). If the reentrancy count has not reached zero, it means that there are still operations dependent on the lock, and it is necessary to wait for other operations to complete.

[0084] In S520, if the reentry count is not zero, it means that other operations are still in progress. The system needs to reduce the reentry count instead of releasing the lock immediately.

[0085] Each time an asynchronous operation completes, the reentrancy count is reduced by 1 until all related operations are completed (i.e., the reentrancy count reaches zero), to ensure the correct timing for releasing the lock.

[0086] In S530, when the reentrancy count reaches zero, the system releases the lock in the application-level state management interface, allowing other asynchronous operations to acquire the lock and continue execution. After the lock is released, the resource becomes available, and other waiting operations can continue.

[0087] In some embodiments of this application, the application-level state management interface stores multiple lock values, each corresponding to a different group of asynchronous operations. Asynchronous operations within the same group are those that need to request access to the same resource. This embodiment is based on... Figure 2 According to the detailed description of steps S300 and S400 in the asynchronous operation execution method shown in the corresponding embodiment, step S300 in the asynchronous operation execution method may include the following steps:

[0088] When it is detected that the application-level state management interface stores the lock value corresponding to the asynchronous operation, the application-level state management interface is checked once every predetermined time until the application-level state management interface no longer stores the corresponding lock value.

[0089] In the asynchronous operation execution method, step S400 may include the following steps:

[0090] When it is detected that the application-level state management interface does not store the lock value corresponding to the asynchronous operation, the corresponding lock value is stored in the application-level state management interface, and the asynchronous operation is executed.

[0091] In this embodiment, by grouping asynchronous operations and assigning each group an independent lock value, the parallel processing capability of multiple asynchronous operations can be improved, maximizing the advantages of multi-core processors and asynchronous operations. Different asynchronous operation groups can be managed with different lock values, thereby avoiding lock contention between multiple operation groups, improving resource utilization, and reducing latency caused by lock contention. Since multiple lock values ​​correspond to different asynchronous operation groups, the same resource is not requested by multiple groups simultaneously, thus reducing the occurrence of deadlocks. Furthermore, through a timed detection mechanism, deadlocks and situations where locks are not released for extended periods can be detected promptly, effectively avoiding performance bottlenecks.

[0092] The following describes an apparatus embodiment of this application, which can be used to execute the asynchronous operation execution method in the above embodiments of this application. For details not disclosed in the apparatus embodiments of this application, please refer to the embodiments of the asynchronous operation execution method described above.

[0093] Figure 5 A block diagram of an asynchronous operation execution apparatus according to an embodiment of this application is shown.

[0094] Reference Figure 5 As shown, an asynchronous operation execution device 500 according to an embodiment of this application includes: an interface call module 510, a lock detection module 520, an operation execution module 530, and a lock release module 540.

[0095] Specifically, the interface invocation module 510 is used to invoke the application-level state management interface in response to the asynchronous operation; the lock detection module 520 is used to detect whether a lock value is stored in the application-level state management interface; the operation execution module 530 is used to store a lock value in the application-level state management interface and execute the asynchronous operation when it is detected that no lock value is stored in the application-level state management interface; and the lock release module 540 is used to release the lock value in the application-level state management interface in response to the completion of the asynchronous operation.

[0096] In some feasible embodiments of this application, the apparatus further includes: a loop detection module, configured to detect the application-level state management interface once every predetermined time period when a lock value is detected stored in the application-level state management interface, until the application-level state management interface no longer stores a lock value.

[0097] In some feasible embodiments of this application, there are multiple lock values, each corresponding to a different group of asynchronous operations; the loop detection module is specifically used to perform the following: when it is detected that the application-level state management interface stores a lock value corresponding to the asynchronous operation, the application-level state management interface is checked once every predetermined time until the application-level state management interface does not store the corresponding lock value; the operation execution module is specifically used to perform the following: when it is detected that the application-level state management interface does not store a lock value corresponding to the asynchronous operation, the corresponding lock value is stored in the application-level state management interface, and the asynchronous operation is executed.

[0098] In some feasible embodiments of this application, the loop detection module specifically includes: a timing submodule, used to start timing when a lock value is detected stored in the application-level state management interface; and a detection submodule, used to detect the application-level state management interface once every predetermined time interval until the application-level state management interface no longer stores a lock value or the timing exceeds a predetermined timeout threshold.

[0099] In some feasible embodiments of this application, the asynchronous operation execution device further includes: a timeout mechanism module, used to automatically trigger the timeout mechanism if the timing exceeds a predetermined timeout threshold.

[0100] In some feasible embodiments of this application, the timeout mechanism module specifically includes: a stop submodule, used to stop the current asynchronous operation and mark the current asynchronous operation as failed if the timeout exceeds a predetermined timeout threshold; and a release submodule, used to release the lock value at the application-level state management interface.

[0101] In some feasible embodiments of this application, each asynchronous operation includes a unique identifier, and the application-level state management interface also stores a unique identifier corresponding to each asynchronous operation that stores a lock value. The operation execution module specifically includes: an operation execution submodule, used to store a lock value in the application-level state management interface and update the unique identifier when it is detected that no lock value is stored in the application-level state management interface, and execute the asynchronous operation; an identifier comparison submodule, used to determine whether the unique identifier of the asynchronous operation is consistent with the unique identifier in the application-level state management interface in response to the detection of the application-level state management interface by the asynchronous operation; and a re-entry count update submodule, used to directly return the state of successful lock value storage and update the re-entry count if the unique identifier of the asynchronous operation is consistent with the unique identifier in the application-level state management interface.

[0102] In some feasible embodiments of this application, the lock release module specifically includes: a zeroing confirmation submodule, used to determine whether the re-entry count has been zeroed in response to the completion of the asynchronous operation; a zeroing execution submodule, used to reduce the value of the re-entry count until the re-entry count is zero if the re-entry count has not been zeroed; and a lock release submodule, used to release the lock value at the application-level state management interface if the re-entry count has been zeroed.

[0103] In this embodiment, a locking mechanism is implemented by storing lock values ​​in the application-level state management interface AppStorage to identify whether a lock is held. This ensures that only one operation can access shared resources at a time during the execution of multiple asynchronous operations, avoiding concurrency conflicts. When multiple asynchronous operations request access to the same resource, this embodiment can reasonably schedule the execution order, avoiding errors or exceptions caused by concurrent execution. Simultaneously, by periodically checking the lock value's status, infinite blocking while waiting for the lock is avoided. This improves the system's response speed and also prevents deadlocks caused by prolonged lock operation.

[0104] Figure 6 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0105] It should be noted that, Figure 6 The computer system of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0106] like Figure 6 As shown, the computer system includes a Central Processing Unit (CPU) 1801, which can perform various appropriate actions and processes based on programs stored in Read-Only Memory (ROM) 1802 or programs loaded from storage portion 1808 into Random Access Memory (RAM) 1803, such as performing the methods described in the above embodiments. The RAM 1803 also stores various programs and data required for system operation. The CPU 1801, ROM 1802, and RAM 1803 are interconnected via a bus 1804. An Input / Output (I / O) interface 1805 is also connected to the bus 1804.

[0107] The following components are connected to I / O interface 1805: an input section 1806 including a keyboard, mouse, etc.; an output section 1807 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1808 including a hard disk, etc.; and a communication section 1809 including a network interface card such as a LAN (Local Area Network) card, modem, etc. The communication section 1809 performs communication processing via a network such as the Internet. A drive 1810 is also connected to I / O interface 1805 as needed. Removable media 1811, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1810 as needed so that computer programs read from them can be installed into storage section 1808 as needed.

[0108] Specifically, according to embodiments of this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program including a computer program for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1809, and / or installed from removable medium 1811. When the computer program is executed by central processing unit (CPU) 1801, it performs various functions defined in the system of this application.

[0109] It should be noted that the computer-readable medium shown in the embodiments of this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disc read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying a computer-readable computer program. The transmitted data signal can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. The computer-readable signal medium can also be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The computer program contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to wireless, wired, etc., or any suitable combination thereof.

[0110] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. Each block in a flowchart or block diagram may represent a module, segment, or portion of code, which contains one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0111] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0112] In another aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs, which, when executed by the electronic device, cause the electronic device to perform the methods described in the above embodiments.

[0113] This specification also provides a computer program product that stores at least one instruction, said at least one instruction being loaded and executed by the processor as described above. Figures 1-4 The method described in the illustrated embodiment can be found in the following document for a detailed execution process. Figures 1-4 The specific details of the illustrated embodiments will not be elaborated here.

[0114] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0115] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, touch terminal, or network device, etc.) to execute the method according to the embodiments of this application.

[0116] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the embodiments disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein.

[0117] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method for executing asynchronous operations, characterized in that, When applied to the ArkTS development system, the asynchronous operation execution method includes: In response to asynchronous operation calls, the application-level state management interface is invoked; Detect whether a lock value is stored in the application-level state management interface; When it is detected that no lock value is stored in the application-level state management interface, the lock value is stored in the application-level state management interface, and the asynchronous operation is executed; In response to the completion of the asynchronous operation, the lock value is released at the application-level state management interface.

2. The asynchronous operation execution method as described in claim 1, characterized in that, The method further includes: When a lock value is detected stored in the application-level state management interface, the application-level state management interface is checked every predetermined time until no lock value is stored in the application-level state management interface.

3. The asynchronous operation execution method as described in claim 2, characterized in that, There are multiple lock values, and each lock value corresponds to a different group of asynchronous operations; When a lock value is detected stored in the application-level state management interface, the application-level state management interface is checked every predetermined time interval until no lock value is stored in the application-level state management interface. Specifically, this includes: When it is detected that the application-level state management interface stores the lock value corresponding to the asynchronous operation, the application-level state management interface is checked once every predetermined time until the application-level state management interface does not store the corresponding lock value. When it is detected that no lock value is stored in the application-level state management interface, the step of storing the lock value in the application-level state management interface and executing the asynchronous operation specifically includes: When it is detected that the application-level state management interface does not store the lock value corresponding to the asynchronous operation, the corresponding lock value is stored in the application-level state management interface, and the asynchronous operation is executed.

4. The asynchronous operation execution method as described in claim 2, characterized in that, When a lock value is detected stored in the application-level state management interface, the application-level state management interface is checked every predetermined time interval until no lock value is stored in the application-level state management interface. Specifically, this includes: The timer starts when a lock value is detected stored in the application-level state management interface; The application-level state management interface is checked once at predetermined intervals until the application-level state management interface no longer stores a lock value or the timeout exceeds a predetermined timeout threshold.

5. The asynchronous operation execution method as described in claim 4, characterized in that, The asynchronous operation execution method further includes: If the timeout exceeds the predetermined timeout threshold, the timeout mechanism will be automatically triggered.

6. The asynchronous operation execution method as described in claim 5, characterized in that, If the timeout exceeds a predetermined timeout threshold, a timeout mechanism will be automatically triggered, specifically including: If the timeout exceeds the predetermined timeout threshold, the current asynchronous operation is aborted and marked as failed. The lock value is released at the application-level state management interface.

7. The asynchronous operation execution method as described in claim 1, characterized in that, Each of the asynchronous operations contains a unique identifier, and the application-level state management interface also stores the unique identifier corresponding to each asynchronous operation that stores the lock value; When it is detected that no lock value is stored in the application-level state management interface, the step of storing the lock value in the application-level state management interface and executing the asynchronous operation specifically includes: When it is detected that no lock value is stored in the application-level state management interface, the lock value is stored in the application-level state management interface and the unique identifier is updated, and the asynchronous operation is performed. In response to the detection of the application-level state management interface by the asynchronous operation, it is determined whether the unique identifier of the asynchronous operation is consistent with the unique identifier in the application-level state management interface; If the unique identifier of the asynchronous operation matches the unique identifier in the application-level state management interface, the system will directly return a state indicating successful storage of the lock value and update the re-entry count.

8. An asynchronous operation execution device, characterized in that, The asynchronous operation execution device includes: The interface call module is used to respond to asynchronous operation calls and call the application-level state management interface; The lock detection module is used to detect whether a lock value is stored in the application-level state management interface; An operation execution module is used to store a lock value in the application-level state management interface and execute the asynchronous operation when it is detected that no lock value is stored in the application-level state management interface. The lock release module is used to release the lock value in the application-level state management interface in response to the completion of the asynchronous operation.

9. A computer-readable medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the asynchronous operation execution method as described in any one of claims 1 to 7.

10. An electronic device, characterized in that, include: One or more processors; A storage device for storing one or more programs, which, when executed by one or more processors, cause the one or more processors to implement the asynchronous operation execution method as described in any one of claims 1 to 7.

Images