Scheduling method and apparatus for parallel events, computing device, storage medium, and program product

Abstract

The present application discloses a scheduling method and apparatus for parallel events, a computing device, a storage medium, and a program product. The scheduling method for parallel events comprises: acquiring a first event, the first event comprising at least one task for a block; in response to the first event comprising a read task for a first object, measuring a value of the first object in the block, the read task being used to read the value of the first object in the block; on the basis of a measurement result, determining whether to terminate execution of the first event.

Description

Method, apparatus, computing device, storage medium, and program product for scheduling parallel events

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application is based on the Chinese patent application with application number 202310717545.3 and application date of June 16, 2023, and claims the priority of the Chinese patent application. The entire content of the Chinese patent application is hereby introduced into this application as a reference. Technical Field

[0003] The present application relates to the field of blockchain technology, and in particular to a scheduling method, apparatus, computing device, storage medium, and program product for parallel events. Background Art

[0004] A blockchain consists of multiple nodes, each of which executes events according to instructions and synchronizes the results of events across the nodes through voting. This decentralized design makes the blockchain open and transparent, attracting more and more events to be completed through the blockchain (such as transfer transactions and contract amendments). To improve the efficiency of blockchain event completion, blockchain nodes allow multiple events to be executed in parallel (for example, by setting up multiple threads). However, when these parallel events involve the same object, conflicts often arise, causing event execution to be slow or even errors. For example, event 1 changes the value of the target object, but event 2, which is executed in parallel, still uses the original value of the target object, resulting in errors in the execution result of event 2. Related technologies lack practical blockchain event scheduling methods to achieve the secure and efficient completion of blockchain events.

[0005] Summary of the Invention

[0006] In view of this, the present application provides a scheduling method and apparatus, system, computing device, computer-readable storage medium, and computer program product for parallel events, which can achieve the secure and efficient completion of blockchain events.

[0007] According to one aspect of the present application, a scheduling method for parallel events is provided, which is executed by a computing device, and includes: obtaining a first event, the first event including at least one task for a block; in response to the first event including a read task for a first object, detecting whether the value of the first object in the block is changed by other events parallel to the first event, the read task being used to read the value of the first object in the block; and, determining whether to terminate execution of the first event based on the detection result.

[0008] According to another aspect of the present application, a scheduling device for parallel events is provided, comprising an acquisition module, a detection module, and an execution module. The acquisition module is configured to acquire a first event, the first event comprising at least one task for a block. The detection module is configured to detect, in response to the first event comprising a read task for a first object, whether the value of the first object in the block has been changed by another event running in parallel with the first event, the read task being used to read the value of the first object in the block. The execution module is configured to determine whether to terminate execution of the first event based on the detection result.

[0009] In a scheduling device for parallel events according to some embodiments of the present application, a reading task includes: determining whether an event database contains a value of a first object, the event database being used to store data of the first event; and, in response to the event database containing the value of the first object, reading the value of the first object from the event database.

[0010] In a scheduling device for parallel events according to some embodiments of the present application, detecting whether the value of a first object in a block is changed by other events parallel to the first event includes: detecting whether the value of the first object in a block database is changed by other events parallel to the first event, the block database being used to store data of the block; the reading task further includes: in response to the event database not containing the value of the first object, reading the value of the first object from the block database.

[0011] In a parallel event scheduling device according to some embodiments of the present application, an event database includes a write task sub-repository and a read task sub-repository, wherein the write task sub-repository is used to store historical data of write tasks, and the read task sub-repository is used to store historical data of read tasks. Reading a value of a first object from the event database includes: determining whether the write task sub-repository contains the value of the first object; in response to determining that the write task sub-repository contains the value of the first object, reading the value of the first object from the write task sub-repository; and, in response to determining that the write task sub-repository does not contain the value of the first object, determining whether the read task sub-repository contains the value of the first object; and in response to determining that the read task sub-repository contains the value of the first object, reading the value of the first object from the read task sub-repository.

[0012] In a scheduling device for parallel events according to some embodiments of the present application, the value of a first object in a block is changed through a write task, and the write task includes: obtaining a write value of the first object; and writing the write value to a location corresponding to the first object in a block database, where the block database is used to store data of the block.

[0013] In a parallel event scheduling device according to some embodiments of the present application, monitoring whether the value of a first object in a block has been changed by another event concurrent with the first event includes sending the first object to a monitoring task as an object to be managed, the monitoring task being used to monitor the object to be managed. The monitoring task includes obtaining the object to be managed and an event corresponding to the object to be managed, monitoring whether the value of the object to be managed has changed, and, in response to the change in the value of the object to be managed, reporting the event corresponding to the object to be managed as at least part of the monitoring result.

[0014] In the parallel event scheduling device according to some embodiments of the present application, determining whether to terminate execution of the first event based on the audiometry result includes: terminating execution of the first event in response to the audiometry result including the first event and the first event not being completed.

[0015] In some embodiments of the present application, the parallel event scheduling apparatus further includes a second determination module and a notification module. The second determination module is configured to, in response to the event including a write task for a second object, determine whether the second object is being monitored by the monitoring task, the write task being used to write the value of the second object in a block. The notification module is configured to, in response to the second object being monitored, notify the monitoring task of a change in the value of the second object.

[0016] In a parallel event scheduling apparatus according to some embodiments of the present application, detecting whether a value of a first object in a block is changed by another event concurrent with the first event includes initiating a detection task for the first object. The detection task includes detecting whether the value of the first object has changed, and in response to the change in the value of the first object, reporting the change in the value of the first object to the first event.

[0017] In the scheduling device for parallel events according to some embodiments of the present application, determining whether to terminate execution of the first event based on the audiometry result includes: instructing the first event to terminate execution in response to a change in the value of the first object and the first event not being completed.

[0018] In the apparatus for scheduling parallel events according to some embodiments of the present application, the apparatus for scheduling parallel events further includes a re-execution module configured to re-execute the first event in response to termination of execution of the first event.

[0019] In the scheduling device for parallel events according to some embodiments of the present application, the events include transactions.

[0020] According to another aspect of the present application, a computing device is provided, comprising: a processor; and a memory configured to store computer-executable instructions thereon, which, when executed in the processor, implement a scheduling method for parallel events as in some embodiments of the present application.

[0021] According to another aspect of the present application, a computer-readable storage medium is provided, in which computer-executable instructions are stored. When the computer-executable instructions are executed on a computer, the computer implements a scheduling method for parallel events as in some embodiments of the present application.

[0022] According to another aspect of the present application, a computer program product is provided, including a computer program. When the computer program is executed by a processor, the scheduling method for parallel events according to some embodiments of the present application is implemented.

[0023] In the method and apparatus for scheduling parallel events claimed in this application, a first event is first acquired, the first event comprising at least one task for a block. Then, in response to the first event comprising a read task for a first object, a test is performed to determine whether the value of the first object in the block has been changed by another event running concurrently with the first event. Because the read task is used to read the value of the first object in the block, it may involve subsequent conflicts. Therefore, testing the first object at this time can achieve significant resource savings with minimal resource consumption. Finally, a determination is made based on the test results to determine whether to terminate execution of the first event.

[0024] It can be seen that in the scheduling method for parallel events disclosed in the embodiment of the present application, whether the value of the first object in the block is changed by other events parallel to the first event is detected to determine whether to terminate the execution of the first event, thereby achieving effective scheduling of events executed in parallel. In particular, when there is a conflict between events executed in parallel, the conflict can be discovered in time and the conflicting event can be accurately terminated based on the conflict, thereby reducing resource consumption and improving event execution efficiency.

[0025] These and other advantages of the application will be apparent from and elucidated with reference to the embodiments described hereinafter. BRIEF DESCRIPTION OF THE DRAWINGS

[0026] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for describing the embodiments. Obviously, the drawings described below are only some embodiments of the present application. Those skilled in the art can also derive other drawings based on these drawings without inventive work, among which:

[0027] FIG1 shows an exemplary application scenario of a scheduling method for parallel events according to some embodiments of the present application;

[0028] FIG2 shows a schematic diagram of the process of event scheduling in the related art;

[0029] FIG3 shows an exemplary flow chart of a method for scheduling parallel events according to some embodiments of the present application;

[0030] FIG4 shows a schematic diagram of a method for scheduling parallel events according to some embodiments of the present application;

[0031] FIG5 shows an exemplary flow chart of some steps of a method for scheduling parallel events according to some embodiments of the present application;

[0032] FIG6 shows a schematic diagram of a write task according to some embodiments of the present application;

[0033] FIG7 shows a schematic diagram of a method for scheduling parallel events according to some embodiments of the present application;

[0034] FIG8 shows an exemplary flow chart of some steps of a method for scheduling parallel events according to some embodiments of the present application;

[0035] FIG9 is a schematic diagram showing a process of a method for scheduling parallel events according to some embodiments of the present application;

[0036] FIG10 shows an exemplary structural block diagram of a scheduling apparatus for parallel events according to some embodiments of the present application; and

[0037] FIG. 11 illustrates an example system including an example computing device representing one or more systems and / or devices that may implement the various methods described in the embodiments of the present application. DETAILED DESCRIPTION

[0038] Example embodiments will now be described more fully with reference to the accompanying drawings. However, example embodiments can be embodied in many forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete and will fully convey the concepts of the example embodiments to those skilled in the art. Like reference numerals in the drawings represent like or similar parts, and thus repetitive description thereof will be omitted.

[0039] In addition, described feature, structure or characteristic can be combined in one or more embodiments in any suitable manner.In the following description, many specific details are provided so as to provide a full understanding of the embodiments of the present application. However, it will be appreciated by those skilled in the art that the technical scheme of the present application can be put into practice without one or more of the specific details, or other methods, components, devices, steps etc. can be adopted. In other cases, known methods, devices, implementations or operations are not shown or described in detail to avoid blurring the various aspects of the application.

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

[0041] The flowcharts shown in the accompanying drawings are for illustrative purposes only and do not necessarily include all information and operations / steps, nor must they be executed in the order described. For example, some operations / steps may be decomposed, while others may be combined or partially combined. Therefore, the actual execution order may vary depending on the actual situation.

[0042] It should be understood that although the terms first, second, third, etc. may be used herein to describe various components, these components should not be limited by these terms. These terms are used to distinguish one component from another. Thus, the first component discussed below can be referred to as the second component without departing from the teachings of the concepts of the present application. As used herein, the term "and / or" and similar terms include all combinations of any, multiple, and all of the associated listed items.

[0043] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program that has a predetermined function and works together with other related parts to achieve a predetermined goal, and can be implemented in whole or in part by using software, hardware (such as processing circuits or memories) or a combination thereof. Similarly, a processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be part of an overall module or unit that includes the function of the module or unit.

[0044] Those skilled in the art will understand that the drawings are merely schematic diagrams of example embodiments, and the modules or processes in the drawings are not necessarily necessary for implementing the present application, and therefore cannot be used to limit the scope of protection of the present application.

[0045] Before introducing the embodiments of the present application in detail, relevant terms are first explained.

[0046] Blockchain: An encrypted, chained transaction storage structure composed of blocks, which can be thought of as a chain of blocks. Each block contains specific information, linked together in chronological order. This chain is stored across all servers, and as long as at least one server in the system is functioning, the entire blockchain is secure. These servers, called nodes in the blockchain system, provide storage space and computing power for the entire system. Modifying information in the blockchain requires the consent of more than half of the nodes and the modification of all nodes. These nodes are often controlled by different entities, making tampering with blockchain information extremely difficult. Compared to traditional networks, blockchains possess two core advantages: data tampering resistance and decentralization. These two characteristics make the information recorded in blockchains more authentic and reliable, helping to address the problem of mutual trust.

[0047] Blockchain Network is a collection of nodes that incorporate new blocks into the blockchain through consensus.

[0048] Block: In blockchain technology, valuable information is permanently stored in the form of data. The carriers used to store data information are called blocks. This valuable information can include transactions, etc.

[0049] Node: In the embodiments of this application, a node refers to a computing device in a blockchain network, such as a computer, server, mobile phone, mining machine, etc. In a distributed system, any machine, such as a server or terminal, can join the blockchain network and become a node. A node includes a hardware layer, an intermediate layer, an operating system layer, and an application layer.

[0050] Peer-to-Peer (P2P) protocol is used to form a P2P network. P2P protocol is an application layer protocol that runs on top of the Transmission Control Protocol (TCP).

[0051] Transaction: Equivalent to the computer term "transaction," a transaction encompasses operations that need to be submitted to a blockchain network for execution. It does not refer solely to transactions in a business context. Given the conventional use of the term "transaction" in blockchain technology, this embodiment of the application follows this convention. All requests within a blockchain network can be referred to as transactions, including but not limited to virtual currency transfer requests, traceability requests, and evidence storage requests.

[0052] Contract: In the blockchain context, this generally refers to a smart contract. A smart contract is a computer protocol designed to communicate, verify, or execute contracts in an information-based manner. Smart contracts allow for trusted transactions without a third party, which are traceable and irreversible. Smart contracts aim to provide superior security compared to traditional contracts and reduce other transaction costs associated with them. In the blockchain, each smart contract typically has a corresponding function or library. When a transaction is executed, the corresponding smart contract function is called for execution.

[0053] Thread: A thread is the basic unit of independent scheduling and dispatching. Threads can be kernel threads scheduled by the operating system kernel, such as Win32 threads; user threads scheduled by user processes, such as POSIX threads on the Linux platform; or a mix of kernel and user processes, such as Windows 7 threads. Multiple threads in the same process share all system resources, such as the virtual address space, file descriptors, and signal handlers. However, multiple threads in the same process have their own call stack, register context, and thread-local storage. A process can have many threads, and multiple tasks can be executed serially on each thread.

[0054] Figure 1 illustrates an exemplary application scenario 100 for a method for scheduling parallel events according to some embodiments of the present application. In some embodiments, application scenario 100 may employ a blockchain system consisting of a client and multiple nodes. The multiple nodes may be comprised of any computing device connected to a network (e.g., a server, a user terminal, etc.). Furthermore, the nodes may form a peer-to-peer network using a peer-to-peer protocol.

[0055] Figure 1 illustrates the functions of each node in a blockchain system. These functions may include routing and applications. Routing, as a basic node function, supports inter-node communication. Applications are deployed within the blockchain to implement specific services based on actual business needs. Specifically, they record data related to the implementation of these functions, creating log data. This log data includes a digital signature to indicate the source of the task data. Furthermore, the log data is transmitted to other nodes in the blockchain system, allowing them to add the data to a temporary block upon successful verification of its source and integrity.

[0056] As examples, applications can implement services such as wallets, shared ledgers, smart contracts, and blockchains.

[0057] In application scenario 100, the scheduling method for parallel events disclosed in this application can be executed at any node in the diagram (e.g., node 101, node 102, etc.). For example, the scheduling method for parallel events can be executed at node 107. First, a first event is obtained, and the first event includes at least one task for a block. Then, in response to the first event including a read task for a first object, the value of the first object in the block is detected, and the read task is used to read the value of the first object in the block. Finally, based on the detection result, it is determined whether to terminate the execution of the first event.

[0058] It should be noted that in the application scenario shown in FIG1 , each node in the system can execute the scheduling method for parallel events described in the embodiment of the present application, and no limitation is imposed here.

[0059] Figure 2 shows a schematic diagram of the process of an event scheduling method in the related art. Figure 2 schematically shows a scheduling method for parallel events in the related art when conflicts occur between events.

[0060] As an example, the events in Figure 2 can be transactions. As shown in Figure 2, event 1 includes a read task for the first object, and event 2 includes a write task for the first object. Event 1 first reads the value of the first object (value 1) and continues to execute. Before event 1 completes execution, event 2 writes the value of the first object, updating the value of the first object to value 2. After event 1 is executed, a conflict occurs. For this reason, event 1 is re-executed, and at this time event 1 will read the first object (value 2) again. This time, event 1 does not generate a conflict after execution is completed, so the execution is successful. It can be seen that in the related technical solution, since the conflict is not discovered in time, event 1 is still executed after the value of the first object changes, which wastes resources and affects the efficiency of event execution.

[0061] Therefore, when handling conflicting events, related technologies typically only discover the difference in object values ​​after the later event completes. At this point, the later event is re-executed based on the updated object value. If the later event takes a long time to execute, it can affect the blockchain's event execution efficiency. For example, if event 1 takes 5 seconds to execute and event 2 takes 3 seconds, the final execution time will be 10 seconds due to untimely termination.

[0062] Figure 3 shows an exemplary flow chart of a method 300 for scheduling parallel events according to some embodiments of the present application. As shown in Figure 3, method 300 can be executed on a blockchain node, such as the node in application scenario 100 shown in Figure 1. Method 300 includes steps S310, S320, and S330.

[0063] In step S310 , a first event is obtained, where the first event includes at least one task for a block.

[0064] As an example, an event includes a transaction, such as a transfer transaction, a contract modification, etc. Also, a transaction may include one or more tasks, such as a read task, a write task, etc.

[0065] In step S320 , in response to the first event including a read task for the first object, it is detected whether the value of the first object in the block is changed by other events concurrent with the first event, the read task being used to read the value of the first object in the block.

[0066] For example, when the first event is a transfer transaction, the first object may be Zhang's account, and the value of the first object may be Zhang's account balance. The other parallel events are any events other than the first event.

[0067] In step S330 , it is determined whether to terminate the execution of the first event based on the audiometry result.

[0068] As an example, the audiometry result may indicate that the value of the first object has changed, or that the value of the first object has not changed. For example, in response to the value of the first object having changed, execution of the first event is terminated. In response to the value of the first object not having changed, execution of the first event is continued.

[0069] Therefore, method 300 realizes effective scheduling of events executed in parallel, especially when there is a conflict between events executed in parallel, it can timely detect the conflict and accurately terminate the conflicting event according to the conflict, which not only reduces resource consumption but also improves the execution efficiency of events.

[0070] In some embodiments, the read task includes determining whether an event database contains a value for a first object, the event database being used to store data of a first event; and, in response to the event database containing the value for the first object, reading the value of the first object from the event database.

[0071] As an example, before each event is executed, a corresponding event database is created for it to store the data involved in the execution of the event. In some embodiments, the event database includes a write task sub-library and a read task sub-library. The write task sub-library is used to store historical data of write tasks, and the read task sub-library is used to store historical data of read tasks. For example, if the first event once read the value of the first object, then the value is stored in its read task sub-library.

[0072] In some embodiments, detecting whether the value of the first object in the block is changed by other events parallel to the first event includes: detecting whether the value of the first object in the block database is changed by other events parallel to the first event, where the block database is used to store data of the block, for example, the block database can store the values ​​of all objects in the block.

[0073] As an example, the read task further includes: in response to the event database not containing the value of the first object, reading the value of the first object from the block database. For example, when the first event includes reading the value of Zhang's account balance, if the event database does not contain the value of Zhang's account balance, then reading from the block database.

[0074] In some embodiments, reading the value of the first object from the event database includes: determining whether the write task sub-library contains the value of the first object; in response to the write task sub-library containing the value of the first object, reading the value of the first object from the write task sub-library; and, in response to determining that the write task sub-library does not contain the value of the first object, determining whether the read task sub-library contains the value of the first object; in response to determining that the read task sub-library contains the value of the first object, reading the value of the first object from the read task sub-library.

[0075] For example, when reading the balance of Zhang's account, if the write task sub-repository of the event database contains the balance of Zhang's account, the balance is read from the write task sub-repository. If the write task sub-repository of the event database does not contain the balance of Zhang's account, but the read task sub-repository does, the balance is read from the read task sub-repository.

[0076] In some embodiments, the value of a first object in a block is changed via a write task, which includes: obtaining a write value for the first object; and writing the write value to the location corresponding to the first object in the block database. For example, if the write task involves writing Zhang's latest account balance to a block, the write value of Zhang's account balance is first obtained; then, the write value is written to the location corresponding to Zhang's account balance in the block database.

[0077] In some embodiments, a separate audiometric task is used to manage objects. For example, a pre-established audiometric task is used to monitor the objects to be managed. For example, if the objects to be managed include object 1, object 2, and object 3, the audiometric task will monitor the values ​​of objects 1, 2, and 3 simultaneously to see if they have changed.

[0078] As an example, monitoring whether the value of a first object in a block has been changed by another event concurrent with the first event may include: sending the first object to a monitoring task as a managed object. Furthermore, the monitoring task may include: obtaining the managed object and an event corresponding to the managed object, monitoring whether the value of the managed object has changed; and, in response to a change in the value of the managed object, reporting the event corresponding to the managed object as at least part of the monitoring result. For example, if the managed object corresponds to event 1, when the value of the managed object changes, the monitoring task may report event 1 as at least part of the monitoring result.

[0079] As an example, determining whether to terminate execution of the first event based on the audiometry result includes: terminating execution of the first event in response to the audiometry result including the first event and the first event not yet being completed. For example, if the audiometry result includes event 1 and event 1 has not yet been completed, then terminating execution of event 1.

[0080] In some embodiments, the value of an object is typically changed by a write task. Therefore, when executing a write task, additional steps may be performed to ensure the smooth progress of the listening task. For example, the additional steps may include: in response to the event to be executed including a write task for a second object (the write task is used to write the value of the second object in the block), determining whether the second object is being listened to by the listening task; and in response to the second object being listened to, notifying the listening task of the change in the value of the second object.

[0081] As an example, when the write task is preparing to write the value of object 2, it will determine whether object 2 is being listened to by the listening task (for example, determine whether object 2 is listed as an object to be managed by the listening task). In response to object 2 being listened to by the listening task, the listening task is notified that the value of object 2 has changed.

[0082] In the embodiment of the present application, when the value of an object changes, the audiometry task object is promptly notified of the value change, so that the executed event can be terminated as early as possible. By terminating the event, the corresponding resources are released, resource waste is reduced, and event execution efficiency is improved.

[0083] In some embodiments, the execution of events (e.g., transactions) can be scheduled by threads. For example, N threads can be set up, each thread will execute at least one event serially, and when multiple of the N threads are executed simultaneously, multiple events are executed in parallel.

[0084] For example, the aforementioned "an independent listening task to manage the object" can be set on a dedicated thread. While events are running on other threads, the listening task on this thread will listen to the managed object in real time. In some embodiments, a main thread with greater authority than other threads can be set to schedule other threads.

[0085] For example, a master thread with greater authority can terminate other threads. For example, a master thread can initiate an event contract thread to execute the event, and initiate a listening thread to perform the listening task. The listening thread will report the thread where the event corresponding to the object whose value has changed. Upon receiving the report, the master thread will proactively stop the thread, thereby terminating the execution of the event on that thread.

[0086] As an example, Figure 4 illustrates a schematic diagram of a method for scheduling parallel events when the main thread has greater authority. As shown in Figure 4 , the main thread initiates a monitoring thread and at least one event contract thread based on the event to be executed (e.g., a transaction). Multiple events can be executed serially on each event contract thread. For each event, the contract function corresponding to the event's contract is called for execution. After initiating multiple threads (i.e., steps 1 and 2 in Figure 4 ), such as event contract thread 1, event contract thread 2, and event contract thread M in Figure 4 , where M is a positive integer greater than 2, the main thread registers the event ID and corresponding thread to be monitored with the monitoring thread (i.e., step 3 in Figure 4 ). The monitoring thread maintains a monitoring list based on the received event ID and corresponding thread. The monitoring list includes corresponding events and threads. The monitoring list can be, for example, the "Event ID and Thread ID Table" shown in the figure, which is used to monitor objects to be managed. An event contract thread typically includes a read or write task (i.e., step 4 in Figure 4). When an event contract thread executes a write task on an object, if that object is a managed object of the listening thread, it triggers a report to the listening thread regarding the object's value change. The report includes the event ID corresponding to that object (i.e., step 5 in Figure 4). The listening thread then notifies the main thread of the thread ID to be stopped. This thread ID is the thread ID corresponding to the event ID in the listening list (i.e., step 6 in Figure 4). The main thread then stops the thread corresponding to that thread ID, thereby terminating the corresponding event (i.e., step 7 in Figure 4) and returns the terminated event ID to the event manager (i.e., step 8 in Figure 4). The event manager then instructs the event corresponding to the event ID to be re-executed (i.e., step 9 in Figure 4). Upon receiving the instruction to re-execute the event, the main thread initiates the re-execution of the event based on the event ID. For example, after the event manager instructs the re-execution of event ID 2, the main thread can instruct the re-execution of the event on thread ID 2000 or re-execute the event on another thread. It should be pointed out that re-executing the event does not mean continuing to execute the event. The benefit of re-execution is that the reliability of the event execution result can be ensured. For example, the event with event ID 2 contains 30 tasks and is terminated when the 15th task is executed. When re-executed, it will not continue from the 15th task, but will be re-executed from the first task. Because the listening thread reports that the value of an object in the event has changed, the reliability of the execution results of the 15 tasks that have been completed at this time is questionable because they are executed based on the unupdated value of the object. Therefore, in an embodiment of the present application, the event is chosen to be re-executed. It should be pointed out that the event manager is used to manage events to be executed, which can be located on a blockchain node (such as each node in scenario 100).Event IDs correspond one-to-one with events, and thread IDs correspond one-to-one with threads. For example, the thread ID corresponding to event contract thread 1 is 1000, and the thread ID corresponding to event contract thread 2 is 2000. As can be seen, in this embodiment of the present application, when the value of the audit object changes, the conflicting event (e.g., conflicting transaction) is terminated promptly and accurately, freeing up the corresponding resources, reducing resource waste and improving event execution efficiency. Furthermore, by re-executing the terminated event (e.g., transaction), the reliability of the execution result is ensured.

[0087] Figure 5 shows an exemplary flow chart of some steps of a scheduling method for parallel events according to some embodiments of the present application. In an embodiment of the present application, the main thread has greater authority. As shown in Figure 5, the scheduling method for parallel events includes steps S510, S520, S530, S540, S550, S560, S570, S580, S590, S591, S592, and S593. In step S510, the main thread will initiate a listening thread for listening to the object to be managed. Subsequently, the contract will be installed. After the contract is successfully installed, the contract execution file is loaded and run (i.e., step S520).

[0088] As an example, a contract execution file includes a contract corresponding to an event (e.g., a transaction) and the corresponding contract function. In step S530, in response to an instruction to execute the event, event contract threads are initiated, and the event will be executed on these threads. In response to executing a read task for a first object, it is determined whether the first object has been tested (i.e., step S540). If the first object has been tested, the process proceeds to step S550; if not, the process proceeds to step S592. In step S592, the first object is sent to the testing task as an object to be managed to implement the testing of the first object, and the process then proceeds to step S550. In step S550, the write task sub-library of the event database is accessed, and the process then proceeds to step S560. In step S560, it is determined whether the first object exists in the write task sub-library. If so, the process proceeds to step S593; if not, the process proceeds to step S570. In step S570, the read task sub-library of the event database is accessed, and the process then proceeds to step S580. In step S580, determine whether the first object exists in the reading task sub-library. If so, go to step S593; if not, go to step S590. In step S590, access the block database, and then go to step S591. In step S591, read the value of the first object from the block database, and add the value of the first object to the event database (for example, add it to the reading task sub-library of the event database), and then go to step S593. In step S593, return the value of the first object. Figure 5 shows some steps of a scheduling method for parallel events, one or more of which can be applied to any of the embodiments listed herein, such as the embodiment for method 300, and is particularly suitable for scenarios where the main thread can terminate other threads, such as in the embodiment shown in Figure 4.

[0089] As an example, one or more of step S540, step S550, step S560, step S570, step S580, step S590, step S591, step S592, and step S593 may be used for the reading task in any of the foregoing embodiments.

[0090] Figure 6 shows a schematic diagram of a write task according to some embodiments of the present application. As shown in Figure 6, the write task may include steps S610, S620, S630, S640, and S650. In step S610, the write set corresponding to the current event (e.g., represented by WriteSet) is obtained. The write set contains multiple key-value pairs, each of which contains an object and its corresponding write value.

[0091] For example, if event 8 writes values ​​to 15 objects, the write set corresponding to event 8 contains 15 key-value pairs. In step S620, flag i is initialized (set to 0). Flag i ensures that all key-value pairs in the write set have been written. In step S630, the key-value pair to be written is retrieved from the write set (the value of the object in the key-value pair to be written can be represented by wkv). Next, a determination is made as to whether a thread is listening to the second object (the second object is the object in the key-value pair to be written). If so, the process proceeds to step S640; otherwise, the process proceeds to step S650. In step S640, the callback function corresponding to the second object is called. This callback function notifies the listening task of the change in the value of the second object. In step S650, the value of the second object is written to the corresponding location in the block database, thereby changing the value of the second object in the block database. The value of flag i is then incremented by 1, and a determination is made as to whether the incremented value is greater than or equal to the number of key-value pairs in the write set. If so, the process ends; otherwise, the process proceeds to step S630. FIG6 shows at least some steps of a writing task, one or more of which may be applied to any of the embodiments listed herein, such as method 300 or the embodiment shown in FIG4 .

[0092] As an example, one or more of steps S610, S620, S630, S640, and S650 may be used for the writing task in any of the above embodiments. For example, step S640 may be used for steps ④ and ⑤ in FIG4 .

[0093] In some embodiments, the audiometry task is invoked by the event itself.

[0094] As an example, detecting whether a value of a first object in a block is changed by another event concurrent with the first event includes initiating a detection task for the first object. The detection task includes detecting whether the value of the first object has changed, and in response to the change in the value of the first object, reporting the change in the value of the first object to a first event.

[0095] As an example, the first event may terminate execution after determining that the value of the first object has changed. In some embodiments, determining whether to terminate execution of the first event based on the audiometry result includes: instructing the first event to terminate execution in response to the value of the first object changing and the first event not yet completing execution.

[0096] As an example, the first event terminates execution when it determines it needs to. For example, when executing event 4, it needs to execute the Read task to read Object 4. At this point, it will call the Listen task to listen to Object 4. When the value of Object 4 changes, the Listen task will report to Event 4 that the value of Object 4 has changed. Event 4 will terminate execution and report an "Execution Error" result. After receiving the "Execution Error" result, the execution node will re-execute event 4. It is important to note that re-executing an event will create a corresponding event database for that event. Therefore, when re-executing an event, the latest value of the object will be read from the block database.

[0097] In some embodiments, although the main thread can schedule other threads, its permissions are limited. For example, the main thread cannot terminate other threads. In this case, other threads are often required to terminate themselves.

[0098] Figure 7 illustrates a schematic diagram of a method for scheduling parallel events when the main thread has limited authority. As shown in Figure 7, the main thread initiates at least one event contract thread based on the event to be executed (e.g., a transaction). Multiple events can be executed serially on each event contract thread. For each event, the contract function corresponding to the event's contract is called for execution. The corresponding event is then executed on the event contract thread. Events typically involve read or write tasks, often writing or reading object values ​​(i.e., step 2 in Figure 7). When an event involves a write task, the value of an object is changed. At this point, if the object is being monitored, the monitoring thread is called back to support the monitoring task (i.e., step 3 in Figure 7). To enable the event contract thread to quickly call back the monitoring thread, a callback interface (i.e., a corresponding call address) is set for each managed object. For example, if event contract thread 5 writes the value of object 1 to the block database, causing the value of object 1 to change, the monitoring task callback can be implemented through the address 127.0.0.1:8090. The monitoring task then reports the change to the corresponding event contract thread. For example, event contract thread 1 is reading the value of object 1. After receiving the report, it will automatically terminate execution and report "error" to the main thread (ie, step ④ in Figure 7). Then, the main thread will return "error" to the event manager (ie, step ⑤ in Figure 7). Finally, the event manager will instruct to re-execute the event that reports "error" (ie, step ⑥ in Figure 7). As an object, in order to determine whether the value of the tested object has changed, in addition to using conventional methods (such as changes in detection values, etc.), it is also possible to verify the registered version of the object's value in the block database. If the registered version is updated, it indicates that the value of the object has been changed.

[0099] In some embodiments, the development language used may not have the ability to notify the parent thread that "the child thread has exited" (general languages ​​have it, such as the panic operation of the golang language, the java language can return error, etc., but there are exceptions), then a variety of solutions can be used to trigger the notification.

[0100] As examples, two solutions are listed below. The first involves checking the call to the contract SDK and exiting directly if necessary. The contract SDK is a library of callable functions provided by the blockchain system to users. Functions such as read and write sets for ledger operations fall under the contract SDK's scope. The second solution involves inserting specific call code at the function entry point or elsewhere during contract compilation. This code is invisible during coding but becomes visible during post-compilation execution. The goal of these solutions is to promptly detect changes in object values ​​and terminate event execution.

[0101] Figure 8 shows an exemplary flow chart of some steps of a method for scheduling parallel events according to some embodiments of the present application. In an embodiment of the present application, the main thread has limited permissions and generally cannot actively terminate other threads. As shown in Figure 8, the method for scheduling parallel events includes steps S810, S820, S830, S840, S850, S860, S550, S560, S570, S580, S590, S591, and S593.

[0102] As an example, steps S860, S550, S560, S570, S580, S590, S591, S592, and S593 may be the same as the corresponding steps shown in Figure 5. In step S810, after the contract is successfully installed, the contract execution file is loaded and executed.

[0103] As an example, a contract execution file includes a contract corresponding to an event (e.g., a transaction) and the corresponding contract function. In step S820, in response to an instruction to execute an event, event contract threads are initiated, and the event will be executed on these threads. In response to the read task for the first object being executed, it is determined whether the first object has been tested (i.e., step S830). If the first object has been tested, the process proceeds to step S550; if the first object has not been tested, the process proceeds to step S840. In step S840, it is determined whether the testing thread has been started. If so, the process proceeds to step S850; if not, the process proceeds to step S860, and the testing thread is started in step S860. In step S850, the first object is sent to the testing task as an object to be managed (e.g., by adding the first object to the testing list) to implement the testing of the first object. In step S550, the write task sub-library of the event database is accessed, and the process proceeds to step S560. In step S560, determine whether the first object exists in the write task sub-library. If so, go to step S593; if not, go to step S570. In step S570, access the read task sub-library of the event database, and then go to step S580. In step S580, determine whether the first object exists in the read task sub-library. If so, go to step S593; if not, go to step S590. In step S590, access the block database, and then go to step S591. In step S591, read the value of the first object from the block database, and add the value of the first object to the event database (for example, add it to the read task sub-library of the event database), and then go to step S593. In step S593, return the value of the first object. Figure 8 shows some steps of a scheduling method for parallel events. One or more of these steps can be applied to any of the embodiments listed herein, such as the embodiment for method 300, and is particularly suitable for scenarios where the main thread cannot terminate other threads, such as the embodiment shown in Figure 7.

[0104] As an example, one or more of step S540, step S550, step S560, step S570, step S580, step S590, step S591, step S592, and step S593 may be used for the reading task in any of the foregoing embodiments.

[0105] In some embodiments, the scheduling method for parallel events further includes: in response to the termination of the execution of the first event, re-executing the first event. It should be noted that re-executing the first event does not mean continuing to execute the first event. For example, the first event contains 20 tasks, and the 10th task has been executed. When re-executing, execution will restart from the first task. In addition, when re-executing the event, a corresponding event database will be re-created for the event. At this time, the latest value of the object will be read from the block database. This ensures that the latest value of the object will be used when the first event is re-executed, thereby ensuring the reliability of the execution result. In addition, since the event is re-executed in a timely manner after the execution of the first event is terminated, the efficiency of event execution can be improved while ensuring the correctness of the execution result. Figure 9 shows a process diagram of the scheduling method for parallel events according to some embodiments of the present application. Figure 9 schematically shows the scheduling method for parallel events performed by an embodiment of the present application when a conflict occurs between events.

[0106] As an example, the events in Figure 9 can be transactions. As shown in Figure 9, event 1 includes a read task for the first object, and event 2 includes a write task for the first object. Event 1 first reads the value of the first object (value 1) and continues to execute. Before event 1 completes execution, event 2 writes the value of the first object and updates the value of the first object to value 2. In response to the change in the value of the first object, event 1 is terminated and re-executed in time. This time, event 1 does not generate a conflict after execution is completed, so the execution is successful. It can be seen that in some embodiments of the present application, since conflicts can be discovered in a timely manner and the execution of conflicting events can be quickly terminated, the effect of saving resources and improving event execution efficiency is achieved.

[0107] Therefore, when handling conflicting events, the embodiments of the present application can promptly detect changes to objects before the conflicting event is completed, thereby quickly terminating the conflicting event and re-executing it earlier based on the updated object value. For example, if the execution time of event 1 is 5 seconds and the execution time of event 2 is 3 seconds, due to the timely termination and re-execution, the final execution time is only 8 seconds.

[0108] FIG10 shows an exemplary structural block diagram of a device 1000 for scheduling parallel events according to some embodiments of the present application. As shown in FIG10 , the device 1000 for scheduling parallel events includes an acquisition module 1010 , an audiometry module 1020 , and an execution module 1030 .

[0109] The acquisition module 1010 is configured to acquire a first event, where the first event includes at least one task for a block.

[0110] As an example, an event includes a transaction, such as a transfer transaction, a contract modification, etc. Also, a transaction may include one or more tasks, such as a read task, a write task, etc.

[0111] The listening module 1020 is configured to listen to whether the value of the first object in the block is changed by other events concurrent with the first event in response to the first event including a read task for the first object, where the read task is used to read the value of the first object in the block.

[0112] As an example, when the first event is a transfer transaction, the first object may be Zhang's account, and the value of the first object may be Zhang's account balance.

[0113] The execution module 1030 is configured to determine whether to terminate the execution of the first event based on the audiometry result.

[0114] As an example, the audiometry result may indicate that the value of the first object has changed, or that the value of the first object has not changed. For example, in response to the value of the first object having changed, execution of the first event is terminated. In response to the value of the first object not having changed, execution of the first event is continued.

[0115] Therefore, the scheduling device 1000 for parallel events can be used to effectively schedule events executed in parallel, especially when there are conflicts between events executed in parallel, the conflicts can be discovered in time and the conflicting events can be accurately terminated based on the conflicts, thereby reducing resource consumption and improving the execution efficiency of events.

[0116] FIG11 illustrates an example system 1100, which includes an example computing device 1110 representing one or more systems and / or devices that can implement the various methods described in the embodiments of the present application. Computing device 1110 can be, for example, a server of a service provider, a device associated with a server, a system on a chip, and / or any other suitable computing device or computing system. The scheduling device 1000 for parallel events described above with reference to FIG10 can take the form of computing device 1110. Alternatively, the scheduling device 1000 for parallel events can be implemented as a computer program in the form of an application 1116.

[0117] The example computing device 1110 as shown includes a processing system 1111, one or more computer-readable media 1112, and one or more I / O interfaces 1113 that are communicatively coupled to each other. Although not shown, the computing device 1110 may also include a system bus or other data and command transmission system that couples various components to each other. The system bus may include any one or a combination of different bus structures, such as a memory bus or memory controller, a peripheral bus, a universal serial bus, and / or a processor or local bus utilizing any one of a variety of bus architectures. Various other examples are also contemplated, such as control and data lines.

[0118] Processing system 1111 represents functionality that uses hardware to perform one or more operations. Thus, processing system 1111 is illustrated as including hardware elements 1114 that may be configured as processors, functional blocks, and the like. This may include hardware implemented as application-specific integrated circuits or other logic devices formed using one or more semiconductors. Hardware elements 1114 are not limited by the materials from which they are formed or the processing mechanisms employed therein. For example, a processor may be comprised of (a plurality of) semiconductors and / or transistors (e.g., electronic integrated circuits (ICs)). In such a context, processor-executable instructions may be electronically executable instructions.

[0119] Computer-readable media 1112 is illustrated as including memory / storage 1115. Memory / storage 1115 represents memory / storage capacity associated with one or more computer-readable media. Memory / storage 1115 may include volatile media (such as random access memory (RAM)) and / or non-volatile media (such as read-only memory (ROM), flash memory, optical disks, magnetic disks, etc.). Memory / storage 1115 may include fixed media (e.g., RAM, ROM, fixed hard drives, etc.) and removable media (e.g., flash memory, removable hard drives, optical disks, etc.). Computer-readable media 1112 may be configured in various other ways, as further described below.

[0120] One or more I / O interfaces 1113 represent functionality that allows a user to input commands and information to the computing device 1110 using various input devices and, in some embodiments, also allows information to be presented to the user and / or other components or devices using various output devices. Examples of input devices include a keyboard, a cursor control device (e.g., a mouse), a microphone (e.g., for voice input), a scanner, touch functionality (e.g., a capacitive or other sensor configured to detect physical touch), a camera (e.g., that can detect motion that does not involve touch as gestures using visible or invisible wavelengths (such as infrared frequencies)), and the like. Examples of output devices include a display device, a speaker, a printer, a network card, a tactile response device, and the like. Thus, the computing device 1110 can be configured in various ways, as further described below, to support user interaction.

[0121] The computing device 1110 also includes an application 1116. The application 1116 may be, for example, a software instance of the scheduling apparatus 1000 for parallel events and, in combination with other elements in the computing device 1110, implements the techniques described herein.

[0122] The present application provides a computer program product or computer program, which includes computer instructions stored in a computer-readable storage medium. A processor of a computing device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computing device to perform the scheduling method for parallel events provided in the various optional implementations described above.

[0123] Various techniques may be described herein in the general context of software, hardware, or program modules. Generally, these modules include routines, programs, objects, elements, components, data structures, and the like that perform specific tasks or implement specific abstract data types. As used herein, the terms "module," "function," and "component" generally refer to software, firmware, hardware, or a combination thereof. The techniques described herein are platform-independent, meaning that these techniques can be implemented on a variety of computing platforms with a variety of processors.

[0124] An implementation of the described modules and techniques may be stored on or transmitted across some form of computer-readable media. Computer-readable media may include a variety of media accessible by computing device 1110.

[0125] By way of example, and not limitation, computer readable media may comprise "computer readable storage media" and "computer readable signal media."

[0126] As opposed to a mere signal transmission, carrier wave, or signal itself, "computer-readable storage medium" refers to a medium and / or device, and / or tangible storage device, capable of persistently storing information. Thus, computer-readable storage media refers to non-signal-bearing media. Computer-readable storage media include hardware such as volatile and non-volatile, removable and non-removable media and / or storage devices implemented in a method or technology suitable for storing information (such as computer-readable instructions, data structures, program modules, logic elements / circuits, or other data). Examples of computer-readable storage media may include, but are not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical storage devices, hard disks, cassettes, magnetic tape, magnetic disk storage devices or other magnetic storage devices, or other storage devices, tangible media, or articles of manufacture suitable for storing desired information and accessible by a computer.

[0127] "Computer-readable signal media" refers to signal-bearing media configured to transmit instructions to the hardware of computing device 1110, such as via a network. Signal media typically embody computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave, data signal, or other transport mechanism. Signal media also include any information delivery media. The term "modulated data signal" refers to a signal that has one or more of its characteristics set or changed so as to encode information in the signal.

[0128] By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

[0129] As before, hardware elements 1114 and computer-readable medium 1112 represent instructions, modules, programmable device logic and / or fixed device logic implemented in hardware form, which can be used to implement at least some aspects of the technology described herein in some embodiments. Hardware elements can include other implementations in integrated circuits or systems on a chip, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs) and silicon or components of other hardware devices. In this context, hardware elements can be used as processing equipment for executing program tasks defined by the instructions, modules and / or logic embodied by the hardware elements, and hardware devices for storing instructions for execution, such as the computer-readable storage media described previously.

[0130] The aforementioned combination may also be used to implement various techniques and modules herein. Therefore, software, hardware or program modules and other program modules may be implemented as one or more instructions and / or logic embodied on some form of computer-readable storage medium and / or by one or more hardware elements 1114. Computing device 1110 may be configured to implement specific instructions and / or functions corresponding to software and / or hardware modules. Therefore, for example, by using a computer-readable storage medium and / or hardware elements 1114 of a processing system, a module may be implemented as a module that can be executed by computing device 1110 as software, at least in part, in hardware. Instructions and / or functions may be executable / operable by one or more articles of manufacture (e.g., one or more computing devices 1110 and / or processing systems 1111) to implement the techniques, modules and examples herein.

[0131] In various embodiments, computing device 1110 can be implemented in a variety of different configurations. For example, computing device 1110 can be implemented as a computer-type device including a personal computer, a desktop computer, a multi-screen computer, a laptop computer, a netbook, etc. Computing device 1110 can also be implemented as a mobile device-type device including mobile devices such as mobile phones, portable music players, portable gaming devices, tablet computers, multi-screen computers, etc. Computing device 1110 can also be implemented as a television-type device, which includes devices having or connected to generally larger screens in casual viewing environments. These devices include televisions, set-top boxes, game consoles, etc.

[0132] The techniques described herein can be supported by these various configurations of computing device 1110 and are not limited to the specific examples of the techniques described herein. Functionality can also be implemented in whole or in part on the "cloud" 1120 using a distributed system, such as through platform 1122 as described below.

[0133] Cloud 1120 includes and / or represents a platform 1122 for resources 1124. Platform 1122 abstracts the underlying functionality of the hardware (e.g., servers) and software resources of cloud 1120. Resources 1124 may include applications and / or data that can be used when executing computer processing on servers remote from computing device 1110. Resources 1124 may also include services provided over the Internet and / or over a subscriber network such as a cellular or Wi-Fi network.

[0134] The platform 1122 can abstract resources and functionality to connect the computing device 1110 with other computing devices. The platform 1122 can also be used to abstract hierarchies of resources to provide a corresponding level of hierarchy in the demand encountered for resources 1124 implemented via the platform 1122. Thus, in an interconnected device embodiment, the implementation of the functionality described herein can be distributed throughout the system 1100. For example, functionality can be implemented partially on the computing device 1110 and through the platform 1122 that abstracts the functionality of the cloud 1120.

[0135] Should be understood that, for the sake of clarity, the embodiments of the present application are described with reference to different functional units. However, it will be apparent that, without departing from the present application, the functionality of each functional unit can be implemented in a single unit, implemented in multiple units or implemented as a part for other functional units. For example, the functionality that is described as being performed by a single unit can be performed by multiple different units. Therefore, reference to a specific functional unit is only considered as a reference to the appropriate unit for providing the described functionality, rather than indicating strict logical or physical structure or organization. Therefore, the application can be implemented in a single unit, or can be physically and functionally distributed between different units and circuits.

[0136] Although the present application has been described in conjunction with some embodiments, it is not intended to be limited to the specific forms set forth herein. On the contrary, the scope of the present application is limited only by the appended claims. Additionally, although individual features may be included in different claims, these may possibly be advantageously combined, and inclusion in different claims does not imply that a combination of features is not feasible and / or advantageous. The order of the features in the claims does not imply any specific order in which the features must work. Furthermore, in the claims, the word "comprising" does not exclude other elements, and the term "a" or "an" does not exclude a plurality. The reference numerals in the claims are provided merely as clear examples and should not be construed as limiting the scope of the claims in any way.

[0137] It is understood that in the specific implementation of this application, user information and other related data are involved. When the above embodiments of this application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

Claims

1. A method for scheduling parallel events, the method being executed by a computing device, the method comprising: Obtaining a first event, wherein the first event includes at least one task for a block; In response to the first event including a read task for a first object, detecting whether the value of the first object in the block is changed by other events in parallel with the first event, the read task being used to read the value of the first object in the block; as well as, Determine whether to terminate the execution of the first event based on the audiometry result.

2. The method according to claim 1, wherein: The reading task includes: determining whether an event database contains a value of the first object, the event database being used to store data of the first event; and, In response to the event database containing a value for the first object, the value for the first object is read from the event database.

3. The method according to claim 2, wherein: The step of detecting whether the value of the first object in the block is changed by other events in parallel with the first event comprises: Listening to whether the value of the first object in a block database is changed by other events that are parallel to the first event, the block database being used to store block data; The reading task includes: In response to the event database not including a value for the first object, the value for the first object is read from the chunk database.

4. The method according to claim 2, wherein: The event database includes a writing task sub-library and a reading task sub-library, wherein the writing task sub-library is used to store historical data of writing tasks, and the reading task sub-library is used to store historical data of reading tasks; The step of reading the value of the first object from the event database comprises: determining whether the write task sub-library contains the value of the first object, In response to determining that the write task sub-library contains the value of the first object, reading the value of the first object from the write task sub-library, and, In response to determining that the write task sub-library does not include the value of the first object, determining whether the read task sub-library includes the value of the first object, and in response to determining that the read task sub-library includes the value of the first object, reading the value of the first object from the read task sub-library.

5. The method according to any one of claims 1 to 4, wherein: The value of the first object in the block is changed by a write task, and the write task includes: Obtaining a written value of the first object; and, The write value is written into a position corresponding to the first object in a block database, where the block database is used to store block data.

6. The method according to any one of claims 1 to 4, wherein: The step of detecting whether the value of the first object in the block is changed by other events that are parallel to the first event includes: Sending the first object to the audiometry task as an object to be managed, wherein the audiometry task is used to audiometry the object to be managed; Wherein, the audiometry task includes: Obtain the object to be managed and the event corresponding to the object to be managed, and detect whether the value of the object to be managed has changed. In response to a change in the value of the object to be managed, an event corresponding to the object to be managed is reported as at least part of the audiometry result.

7. The method according to claim 6, wherein: The determining whether to terminate the execution of the first event based on the audiometry result includes: In response to the audiometry result including the first event and the first event has not been completed, terminating the execution of the first event.

8. The method according to claim 6, wherein: The method further comprises: In response to the event comprising a write task for a second object, determining whether the second object is listened to by a listening task, the write task being used to write a value of the second object in a block; and In response to the second object being listened to, the listening task is notified that a value of the second object has changed.

9. The method according to any one of claims 1 to 8, wherein: The step of detecting whether the value of the first object in the block is changed by other events in parallel with the first event comprises: Initiating an audiometry task for the first object, the audiometry task comprising: detecting whether the value of the first object changes, In response to the value of the first object changing, reporting the change in the value of the first object to the first event.

10. The method according to claim 9, wherein: The determining whether to terminate the execution of the first event based on the audiometry result includes: In response to the value of the first object being changed and the first event not being completed, instructing the first event to terminate execution.

11. The method according to claim 7 or 10, wherein: The method further comprises: In response to the first event execution being terminated, the first event is re-executed.

12. The method according to any one of claims 1 to 10, wherein: The events include transactions.

13. A scheduling device for parallel events, comprising: An acquisition module, configured to acquire a first event, wherein the first event includes at least one task for a block; an audio detection module, configured to detect whether the value of the first object in the block is changed by other events in parallel with the first event in response to the first event including a read task for the first object, the read task being used to read the value of the first object in the block; as well as, An execution module is configured to determine whether to terminate the execution of the first event based on the audiometry result.

14. A computing device comprising: processor; as well as A memory configured to store thereon computer executable instructions, which, when executed in the processor, enable the method of any one of claims 1 to 12 to be implemented.

15. A computer-readable storage medium, wherein computer-executable instructions are stored in the computer-readable storage medium. When the computer-executable instructions are executed on a computer, the computer is enabled to implement the method according to any one of claims 1 to 12.

16. A computer program product comprising a computer program which, when executed by a processor, causes the method according to any one of claims 1 to 12 to be implemented.

Images