Time Management Method, Device, Equipment and Medium Supporting Asynchronous External Calls

Abstract

The present application relates to a time management method, device, equipment and medium supporting asynchronous external calls. The method includes: after the parallel simulation is started, multiple simulation processes load simulation objects and process events. Each process is provided with multiple event queues. When an event is processed by a thread, if an external call is triggered, a data structure including a queue number, a timestamp, a thread context and a call serial number is created in the event queue and added to the linear data structure in the order of the timestamp. If the length exceeds the upper limit, the thread is destroyed; otherwise, the processing continues. If no external call is triggered, it is checked whether there is a return result of a previous call, and the event with the smallest timestamp is selected for processing and then the subsequent events are continued. The main thread listens for the return of the external call, records it with an ordered structure, and finds the associated queue according to the serial number. If there is an event to be processed in the queue, the returned event is added to the returned queue; otherwise, the event is processed. By adopting this method, asynchronous external calls can be supported, and the problem of simulation engine blockage can be solved.

Description

Technical Field

[0001] This application relates to the field of simulation technology, and particularly to a time management method, device, equipment and medium that support asynchronous external calls. Background Art

[0002] During the simulation operation, time-consuming model algorithms are often called, such as radar resolution. Traditional simulation engines mostly use synchronous call modes, that is, the radar algorithm is called in the main thread (or main simulation thread) of the running simulation engine, and the simulation continues to execute forward only after the return of the algorithm call, as shown in Figure 1 (a). In some simulation systems, in order to maintain the independence and professionalism of the algorithm system, the algorithms used in the simulation are separately implemented as algorithm services, as shown in Figure 1 (b). In the remote call mode, the algorithm service generally provides special hardware support for algorithm operation, such as GPU hardware, and supports the operation of multiple call instances, bringing greater flexibility to the simulation operation. In the remote call mode, its call process generally includes at least three steps: (1) Submitting a call, that is, submitting a call application to the algorithm server; (2) Waiting for the call to return, waiting for the algorithm service to return the call result; (3) Call return, the algorithm service completes the calculation and returns the calculation result to the simulation thread of the simulation engine. In the synchronous call mode, when the call is submitted, the simulation engine enters a blocked state and waits for the result to return. Only after the call returns can the simulation thread of the simulation engine resume running. It is not difficult to see from the above process that in the synchronous call mode, when the external call waiting time is relatively long, the simulation thread of the simulation engine will also be in a waiting state, that is, the simulation engine is blocked, and the external manifestation is that the simulation engine "gets stuck" there. For example, after a certain aircraft simulation object uses the synchronous mode to call the radar detection algorithm, the simulation engine blocks and stops. At this time, other aircraft simulation objects cannot process events (including updating positions). From the external manifestation, all aircraft stop in the air, which is unreasonable both in terms of objective reality and simulation efficiency. Therefore, for external calls, an asynchronous call mode is generally adopted, that is, after the simulation object submits an external call, it no longer waits, but hands over the control right of the simulation engine, and the simulation engine can process the events of other simulation objects, enabling the simulation to continue to advance.

[0003] Therefore, to solve the above problems, it is necessary to propose an asynchronous call algorithm and related devices to support the simulation engine to initiate external call requests asynchronously. After that, the simulation engine can still normally schedule and process other events that can be safely processed. However, in the asynchronous call mode, simulation time errors may occur. Some simulation objects are waiting for the call to return (at this time, their simulation clocks have not advanced), while those simulation objects that have not submitted external calls can advance. Then, these waiting simulation objects will be missed when calculating the global virtual time (GVT), resulting in an incorrect GVT calculation and the simulation objects cannot continue to execute from the return point after the external call is initiated and the call returns. Summary of the Invention

[0004] Based on this, it is necessary to provide a time management method, device, computer device, and storage medium that support asynchronous external calls, solve the problem of simulation engine blocking, and improve simulation efficiency for the above technical problems.

[0005] A time management method that supports asynchronous external calls, the method includes:

[0006] The parallel simulation starts to run, multiple simulation processes are started to load all simulation objects and start processing events; multiple event queues are set in each simulation process, and each event queue is processed by a thread in ascending order of the timestamps of the events in the event queue; there is also a main thread in each simulation process, and each event queue maintains an ordered linear data structure;

[0007] During the process of the simulation thread processing events, it checks whether an external call is triggered. When an external call is triggered by a simulation thread, a data structure is created in the event queue; the data structure includes the current event queue number, the timestamp of the event being processed by the current simulation thread, the saved simulation thread context when the external call is triggered, and the serial number of the external call; the data structure is added to the linear data structure according to the timestamp of the data structure and sorted according to the timestamp. If the length of the linear data structure is greater than the preset upper limit of the number of external calls, the current simulation thread is destroyed. If the length of the linear data structure is not greater than the upper limit of the number of external calls, the simulation thread continues to process the events in the queue;

[0008] If no external call is triggered during the process of the simulation thread processing events, it checks whether there is a previously triggered external call that has returned a result. Select the event with the smallest timestamp from the external calls that have returned results, continue to process the event according to the return result, and then return to the event queue to take out the head event and continue to process subsequent events;

[0009] The main thread listens for the return of an external call. After the external call returns, it is recorded using an ordered linear data structure. The associated event queue is determined based on its call sequence number, and it is checked whether there are events to be processed in the event queue. If there are events to be processed in the event queue, the event is added to the returned queue; if not, the relevant events are processed according to the return result of the external call.

[0010] In one embodiment, in a parallel simulation process, a simulation process is randomly defined as the main process. The main process periodically sends GVT calculation messages, which contain the calculated temporary GVT. Other simulation processes outside the main process receive the GVT calculation message and mark this process as "in GVT calculation": set the current process state to be in the process of GVT calculation to distinguish it from other non-calculation states; if a simulation process is in the "in GVT calculation" state, then each simulation thread it contains reduces and calculates the minimum timestamp of the messages it sends when sending messages. ;

[0011] Calculate the local GVT, take the minimum value of the local GVT and the temporary GVT in the GVT calculation message as the temporary GVT in the forwarded GVT calculation message and send it to the next process to complete the calculation of the global virtual time in a multi-threaded environment.

[0012] In one embodiment, the process of local GVT calculation includes:

[0013] When sending events, the minimum timestamp of all sent events in the "in GVT calculation" stage has been reduced and calculated, that is and all arrived events have been sorted in the event queue, and its minimum timestamp has been reduced to Therefore, the local GVT is .

[0014] In one embodiment, the timestamp when the current simulation thread is processing an event is the sorting basis for adding the data structure to the linear data structure.

[0015] In one embodiment, the sequence number of the external call is used to identify which event triggered the external call, and then activate this simulation thread to continue processing this event.

[0016] A time management device supporting asynchronous external calls, the device includes:

[0017] An event queue setting module is used to start parallel simulation, launch multiple simulation processes to load all simulation objects and start processing events; in each simulation process, multiple event queues are set up, and each event queue is processed by a thread in ascending order of the timestamps of the events in the event queue; there is also a main thread in each simulation process, and each event queue maintains an ordered linear data structure;

[0018] A trigger external call and data structure design module is used to check whether an external call is triggered during the process of a simulation thread processing an event. When an external call is triggered by a simulation thread, a data structure is created in the event queue; the data structure includes the current event queue number, the timestamp of the event being processed by the current simulation thread, the saved simulation thread context when the external call is triggered, and the sequence number of the external call; the data structure is added to the linear data structure according to the timestamp of the data structure and sorted by the timestamp. If the length of the linear data structure is greater than the preset upper limit of the number of external calls, the current simulation thread is destroyed. If the length of the linear data structure is not greater than the upper limit of the number of external calls, the simulation thread continues to process the events in the queue;

[0019] An event processing module for untriggered external calls is used to check whether there is a result returned by a previously triggered external call if no external call is triggered during the process of a simulation thread processing an event, select the event with the smallest timestamp from the already returned external calls, continue to process the event according to the returned result, and then return to the event queue to take out the head event and continue to process subsequent events;

[0020] A main thread listening module is used to listen for the return of an external call. When the external call returns, it is recorded using the ordered linear data structure, the associated event queue is determined according to its call sequence number, and it is judged whether there is an event to be processed in the event queue. If there is an event to be processed in the event queue, the event is added to the returned queue; if not, the relevant event is processed according to the return result of the external call.

[0021] A computer device includes a memory and a processor. The memory stores a computer program. When the processor executes the computer program, the following steps are implemented:

[0022] Start parallel simulation, launch multiple simulation processes to load all simulation objects and start processing events; in each simulation process, set up multiple event queues, and each event queue is processed by a thread in ascending order of the timestamps of the events in the event queue; there is also a main thread in each simulation process, and each event queue maintains an ordered linear data structure;

[0023] During the process of a simulation thread handling an event, it checks whether an external call is triggered. When an external call is triggered by a simulation thread, a data structure is created in the event queue. The data structure includes the current event queue number, the timestamp of the event being processed by the current simulation thread, the saved context of the simulation thread when the external call was triggered, and the sequence number of the external call. The data structure is added to the linear data structure according to the timestamp of the data structure and sorted by the timestamp. If the length of the linear data structure is greater than the preset upper limit of the number of external calls, the current simulation thread is destroyed. If the length of the linear data structure is not greater than the upper limit of the number of external calls, the simulation thread continues to process the events in the queue.

[0024] If no external call is triggered during the process of a simulation thread handling an event, it checks whether there is a result returned by a previously triggered external call. It selects the event with the smallest timestamp from the externally called events that have returned results, continues to process the event based on the returned result, and then returns to the event queue to fetch the head event and continue to process subsequent events.

[0025] The main thread listens for the return of an external call. When the external call returns, it is recorded using the ordered linear data structure. The associated event queue is determined according to its call sequence number, and it is judged whether there is an event to be processed in the event queue. If there is an event to be processed in the event queue, the event is added to the returned queue. If not, the relevant event is processed according to the return result of the external call.

[0026] A computer-readable storage medium stores a computer program thereon. When the computer program is executed by a processor, the following steps are implemented:

[0027] Parallel simulation starts running, and multiple simulation processes are started to load all simulation objects and start processing events. Multiple event queues are set up in each simulation process, and each event queue is processed by a thread in ascending order of the timestamps of the events in the event queue. There is also a main thread in each simulation process, and each event queue maintains an ordered linear data structure.

[0028] During the process of a simulation thread handling an event, it checks whether an external call is triggered. When an external call is triggered by a simulation thread, a data structure is created in the event queue. The data structure includes the current event queue number, the timestamp of the event being processed by the current simulation thread, the saved context of the simulation thread when the external call was triggered, and the sequence number of the external call. The data structure is added to the linear data structure according to the timestamp of the data structure and sorted by the timestamp. If the length of the linear data structure is greater than the preset upper limit of the number of external calls, the current simulation thread is destroyed. If the length of the linear data structure is not greater than the upper limit of the number of external calls, the simulation thread continues to process the events in the queue.

[0029] If no external call is triggered during the simulation thread's processing of an event, check whether there is a previously triggered external call that has returned a result. Select the event with the smallest timestamp from the externally called functions that have returned results, continue to process the event based on the returned result, and then return to the event queue to retrieve the head event and continue to process subsequent events;

[0030] The main thread listens for the return of an external call. When the external call returns, record it using an ordered linear data structure. Determine the associated event queue based on its call sequence number, and check whether there is an event to be processed in the event queue. If there is an event to be processed in the event queue, add the event to the returned queue; if not, process the relevant event according to the return result of the external call.

[0031] The above time management method, device, computer equipment and storage medium that support asynchronous external calls. In this application, multiple event queues are first set up for the simulation process. When each simulation thread initiates an external call, the event queue records key context data, including the current event queue number, the timestamp of the event being processed by the current simulation thread, the saved simulation thread context when the external call is triggered, and the serial number of the external call. The events are sorted by the timestamp to form a linear data structure, ensuring the orderliness and consistency of event processing. Especially when multiple external calls occur, the event queue can accurately maintain the simulation clock, avoiding the global stagnation phenomenon caused by waiting in the traditional synchronous mode. This mechanism improves the efficiency of event management and provides basic support for subsequent asynchronous calls. At the same time, since the linear data structure is sorted, the minimum timestamp of the events in the linear data structure is the global virtual time, avoiding the problem of incorrect GVT calculation. By assigning a unique serial number to each external call, the simulation engine can quickly locate the corresponding simulation thread and its context after the call returns. After positioning, the simulation thread can resume seamlessly, destroy the record of the completed call in the linear data structure, and release resources. The efficiency of this mechanism lies in avoiding the overall simulation pause problem caused by the blocking of simulation threads in the synchronous call mode, while achieving accurate simulation thread management. This approach also reduces the additional overhead of simulation thread switching and improves the operating efficiency of the system. Then, setting the external call number threshold introduces a dynamic load control means for the simulation system. When the external call reaches the set threshold, the event queue suspends the current simulation thread to avoid resource overload; when the simulation thread is suspended, the system allocates idle simulation threads from the simulation thread pool to process other events. This mechanism not only avoids the excessive occupation of system resources caused by the backlog of external calls, but also ensures that the simulation engine can continue to advance. Through the dynamic allocation and limitation of resources, this technical means effectively balances the call performance and the stability of the simulation engine. When the upper limit of suspended waiting simulation threads is reached, the simulation thread pool mechanism ensures the dynamic allocation of available simulation threads. In the case of not reaching the upper limit, idle simulation threads will be allocated to process events, avoiding the global efficiency decline caused by the blocking of a single simulation thread. This on-demand allocation method improves the parallel processing ability of the simulation engine, especially showing significant advantages in complex scenarios. Based on the linear data structure sorted by timestamp and event queue management, it ensures the time consistency after the completion of asynchronous external calls. In asynchronous calls, some simulation objects wait for the return of external calls, while other objects can continue to run, avoiding the problem of global clock stagnation in the traditional mode. At the same time, after the external call returns, the accurate recovery mechanism at the call point ensures the coherence of the simulation logic, without introducing logical jumps or timing chaos due to asynchronous calls. This application enables the simulation engine to handle multiple external calls and simulation events simultaneously, greatly improving the parallel ability of the simulation.Avoid the blocking problem caused by the long waiting of a single external call in the synchronous call mode, and ensure the continuous progress of the simulation engine. In the case of limited resources, the dynamic threshold and simulation thread pool mechanism optimize resource allocation, maximizing the operating efficiency and stability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Figure 1 FIG. is a schematic diagram of a simulation engine using a synchronous call mode in an embodiment; wherein, Figure 1 (a) is a schematic diagram of calling a radar algorithm in the main thread of the running simulation engine and continuing to execute forward after the return of the algorithm call, Figure 1 (b) is a schematic diagram of implementing the algorithms used in the simulation as separate algorithm services in some simulation systems in order to maintain the independence and professionalism of the algorithm system;

[0033] Figure 2 FIG. is a schematic flowchart of a time management method supporting asynchronous external calls in an embodiment;

[0034] Figure 3 FIG. is an event processing flowchart in an embodiment;

[0035] Figure 4 FIG. is a schematic diagram of the process after the external call returns in an embodiment;

[0036] Figure 5 FIG. is a schematic flowchart of the GVT processing in an embodiment;

[0037] Figure 6 FIG. is a structural block diagram of a time management device supporting asynchronous external calls in an embodiment;

[0038] Figure 7 FIG. is an internal structure diagram of a computer device in an embodiment. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0039] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0040] In one embodiment, as shown in Figure 2 and Figure 3 , a time management method supporting asynchronous external calls is provided, including the following steps:

[0041] Step 102, the parallel simulation starts running, launching multiple simulation processes to load all simulation objects and start processing events; in each simulation process, multiple event queues are set up, and each event queue is processed by a thread in ascending order of the timestamps of the events in the event queue; there is also a main thread in each simulation process, and each event queue maintains an ordered linear data structure.

[0042] Design a data structure to record external calls waiting for return, support GVT calculation and reactivate suspended threads. Assume the simulation engine sets n event queues, and require that each event queue has at least one thread to process its events. Each event queue maintains an ordered linear data structure asycall_record. Whenever a thread initiates an external call, it creates a data structure asycall_entry (eq i , t asy , th_context i , serial asy ), where eq i represents the current event queue number, t asy represents the timestamp of the event being processed by the current thread, and at the same time uses this value as the sorting basis for asycall_entry to be added to asycall_record. th_context i represents the thread context saved when the external call is triggered, and serial asy represents the serial number of the external call, which is immediately returned by the external service system after the external call is submitted. When the result of the external call is returned, use serial asy to locate which event triggered the external call, associate the saved thread context data, and then continue to process this event.

[0043] Launch multiple simulation processes to load all simulation objects, so that multiple simulation objects can be processed simultaneously in different threads, providing an infrastructure for asynchronous calls. Different simulation threads can independently initiate external call requests without interfering with each other. When a certain simulation thread initiates an external call, other threads can still continue to process their own events, realizing the asynchronization of multiple simulation object processing and external calls, and avoiding the situation where the external call blocks the entire simulation process in a single thread.

[0044] Each simulation thread sets up multiple event queues to process events in parallel, maximizing the utilization of computer performance. In this way, when processing events, especially in cases involving external calls, each event queue can operate independently. When an event in an event queue triggers an external call, it will not affect the normal processing of events in other event queues, further enhancing the asynchronous processing ability and enabling the simulation engine to handle various events and external calls more flexibly. The event queue maintains an ordered linear data structure and processes events in timestamp order, ensuring the orderliness and rationality of event processing. In an asynchronous call environment, this helps the simulation engine manage and schedule resources more efficiently. For example, for some events that depend on a specific order, such as initializing the environment first and then performing object interactions, processing them in timestamp order can ensure the correct execution order of these events, avoiding errors and conflicts caused by disordered order and ensuring the correctness and stability of the simulation.

[0045] The setting of multiple simulation threads and event queues can achieve load balancing. Different simulation objects and events may have different computational amounts and processing difficulties. By allocating them to different threads and event queues, the system resources can be utilized more fully and evenly. During asynchronous calls, each thread can flexibly process events and initiate external calls according to its own load situation, without the situation where a certain thread is overloaded while other threads are idle, thus improving the performance and efficiency of the entire simulation system. This architecture of multiple threads and multiple event queues has good scalability. As the scale of the simulation system expands and its functions increase, simply adding new simulation threads and event queues can easily accommodate more simulation objects and events and support more external calls. In an asynchronous call scenario, it can conveniently handle the growing business requirements and enable the simulation system to better adapt to simulation tasks of different scales and complexities.

[0046] Step 104: During the process of a simulation thread processing an event, check whether an external call is triggered. When an external call is triggered by a simulation thread, create a data structure in the event queue; the data structure includes the current event queue number, the timestamp of the event being processed by the current simulation thread, the saved simulation thread context when the external call is triggered, and the serial number of the external call; add the data structure to the linear data structure according to the timestamp of the data structure and sort it by timestamp. If the length of the linear data structure is greater than the preset upper limit of the number of external calls, destroy the current simulation thread. If the length of the linear data structure is not greater than the upper limit of the number of external calls, the simulation thread continues to process the events in the queue.

[0047] When there is a return result from an external call, with serial asyLocate the saved thread context data, and use this data to continue processing events. At the same time, destroy the corresponding asycall_entry when asycall_record is destroyed. To avoid too many threads being suspended and activated, set an upper limit Nasy on the number of external calls that can wait in the event queue simultaneously. Before submitting an external call, query the length of asycall_record. If it is greater than Nasy, suspend the current thread; otherwise, submit the external call normally.

[0048] When the simulation thread triggers an external call, instead of making the entire simulation engine wait, create a data structure containing key information, namely the thread context. This enables the simulation thread to continue processing other tasks after triggering an external call without blocking and waiting for the call to complete, truly realizing asynchronous operation, allowing the simulation engine to perform multiple tasks simultaneously, improving the concurrency and response ability of the system. Add a data structure with information such as timestamps to a linear data structure and sort it, providing an ordered management method for asynchronous calls to reduce simulation latency and possible rollbacks. The timestamp can be an important basis for resuming execution after an asynchronous call returns, ensuring that even in the case of multiple concurrent asynchronous calls, subsequent processing can be carried out in the correct order without confusion, guaranteeing the correctness and stability of asynchronous operations. Determine whether to destroy the current simulation thread or create a new one by judging the relationship between the number of external calls waiting for return results and the upper limit of the number of external calls. This provides a basis for dynamic adjustment of the resource management of the simulation engine, enabling the simulation engine to reasonably allocate computing resources according to the actual situation of external calls, avoiding resource exhaustion or excessive idleness caused by too many external call requests, and ensuring the flexibility and efficiency of the simulation engine scheduling. Save the simulation thread context when an external call is triggered, enabling execution to resume from the correct position after the external call returns, just as if it had not been interrupted. This helps the simulation engine to schedule methodically when dealing with complex external call scenarios, without problems such as thread chaos or data loss due to external call interference, ensuring the reliability and stability of the simulation engine scheduling.

[0049] Sort the data structure according to timestamps, enabling the data related to external calls to be managed under the same rules as other event data. When an external call returns, the corresponding event can be accurately found and processing can continue without omission or incorrect handling, thus ensuring the integrity of all event processing. Whether it is an event related to an external call or other internal events, they can all be correctly processed under the orderly scheduling of the simulation engine.

[0050] Step 106, if no external call is triggered during the process of the simulation thread handling an event, check whether there is a previously triggered external call that has returned a result. Select the event with the smallest timestamp from the externally called events that have returned results, continue to process the event based on the returned result, and then return to the event queue to retrieve the head event and continue to process subsequent events.

[0051] In the asynchronous call mode, after submitting an external call, the simulation object does not wait but continues to advance other processable events. When the simulation process handles an event without triggering a new external call, it checks the return results of previous external calls, can promptly utilize this returned information, and enables the corresponding event to continue to be processed. This ensures that the entire process from initiating an external call, waiting, to using the result is coherent, and the processing of related events will not be stalled due to waiting for the call result, achieving seamless connection between asynchronous calls and the simulation process, enabling the simulation engine to fully utilize the time gap returned by external calls and continuously advance the simulation.

[0052] Selecting the event with the smallest timestamp from the externally called events that have returned results follows the principle of chronological order. Events in a simulation usually have a chronological association, and processing them in timestamp order can ensure that event processing is logical. In aircraft flight simulation, the radar detection results that are returned first may affect the processing of subsequent flight path planning events. This approach avoids chaos in event processing, reduces errors and repeated calculations caused by improper processing order, and improves the overall efficiency of simulation processing.

[0053] At the same time, it enables the simulation engine to, while processing the returned results of external calls, also normally retrieve the head event from the event queue to process subsequent events. This means that the simulation engine will not be blocked by the processing of the returned results of external calls and always maintains normal scheduling of the event queue. Regardless of the return situation of external calls, the simulation engine can orderly advance the processing of other events, fully utilize system resources, ensure the continuous operation of the simulation system, and prevent scheduling stagnation caused by external call-related processing, thereby maintaining the fluency and stability of the simulation.

[0054] Step 108, the main thread listens for the return of external calls. When an external call returns, it records it using an ordered linear data structure, determines the associated event queue according to its call serial number, and checks whether there is an event to be processed in the event queue. If there is an event to be processed in the event queue, add the event to the returned queue; if not, process the relevant event according to the return result of the external call.

[0055] Each process has a main thread to listen for: the return of external calls, GVT calculation requests (in a parallel simulation system, GVT calculations are performed regularly. The basic process is to poll the local GVT of each process and then perform a global reduction to find the minimum value.). When an external call returns, follow the following Figure 4As shown, after the external call returns, it is recorded using the ordered linear data structure returned_invoke. The associated event queue is determined based on its call sequence number, and it is judged whether there is a processing event in the event queue. If there is a processing event in the event queue, the event is added to the returned queue; if not, the relevant events are processed according to the return result of the external call.

[0056] In the asynchronous call mode, after the simulation object submits an external call, it does not wait but continues to advance the simulation. At this time, the main thread of each thread is responsible for listening for the return of the external call. Once the external call returns, the main thread can quickly capture this information, avoiding the simulation engine from being blocked due to waiting for the external call result. This enables the simulation engine to continuously process the events of other simulation objects while the external call is in progress, ensuring the fluency and efficiency of the simulation and solving the problem of simulation engine blockage in the traditional synchronous call mode. After the external call returns, it is recorded using the ordered linear data structure returned_invoke. This ordered recording method helps to efficiently manage and search for the return results later. The associated event queue can be quickly determined through the call sequence number, enabling the simulation engine to accurately find the events related to the external call, providing convenience for subsequent processing, ensuring that the asynchronous call results can be correctly processed, and further supporting the smooth operation of the asynchronous call mechanism. At the same time, the main thread listens for GVT calculation requests simultaneously, which is a key link to ensure the correct calculation of GVT. The parallel simulation system performs GVT calculation regularly, and needs to poll the local GVT of each thread and perform a global reduction to find the minimum value. The main thread's listening for GVT calculation requests enables the thread to respond to the system's GVT calculation requirements in a timely manner and provide accurate local GVT information. In an asynchronous call environment, the states and event processing situations of each thread are relatively complex. Through this listening mechanism, it can be ensured that the local GVT information of each thread obtained during the GVT calculation process is the latest and most accurate, so as to obtain the correct global virtual time. After the external call returns, it is decided how to process the relevant events according to the processing status of the event queue. If the event queue is processing an event, the event is added to the returned queue; if there is no processing event, the relevant events are processed according to the return result. This processing method ensures the consistency between event processing and GVT calculation. During the GVT calculation process, the timestamps and processing statuses of all events need to be considered. By reasonably processing the external call return event, it can be ensured that the time sequence and status of event processing meet the requirements of GVT calculation, avoiding GVT calculation errors caused by improper event processing.

[0057] Moreover, by determining whether there are events to be processed in the event queue, the processing method of the returned events for external calls is decided, optimizing the event processing flow. When the event queue is processing other events, the returned events are added to the returned queue, avoiding interference with the currently processed events and ensuring the continuity and efficiency of event processing. When the event queue is idle, relevant events are processed in a timely manner according to the return results, reducing the latency of event processing and improving the overall efficiency of the simulation. Orderly recording the return results of external calls and reasonably processing relevant events reduces system errors and exceptions caused by improper handling of asynchronous call return results. The monitoring mechanism of the main thread ensures timely response to external call returns and GVT calculation requests, enabling the simulation system to operate stably in a complex asynchronous environment and improving the reliability and stability of the system.

[0058] In the above time management method that supports asynchronous external calls, multiple event queues are first set up for the simulation process. When each simulation thread initiates an external call, the event queue records key context data, including the current event queue number, the timestamp of the event being processed by the current simulation thread, the saved simulation thread context when the external call is triggered, and the serial number of the external call. Sorting the events by the timestamp forms a linear data structure, ensuring the orderliness and consistency of event processing. Especially when multiple external calls occur, the event queue can accurately maintain the simulation clock, avoiding the global stagnation phenomenon caused by waiting in the traditional synchronous mode. This mechanism improves the efficiency of event management and provides basic support for subsequent asynchronous calls. By assigning a unique serial number to each external call, the simulation engine can quickly locate the corresponding simulation thread and its context after the call returns. After positioning, the simulation thread can resume seamlessly, destroy the records of the completed calls in the linear data structure, and release resources. The efficiency of this mechanism lies in avoiding the overall simulation pause problem caused by the blocking of simulation threads in the synchronous call mode, while achieving accurate simulation thread management. This approach also reduces the additional overhead of simulation thread switching and improves the operating efficiency of the system. Then, setting the external call number threshold introduces a dynamic load control means for the simulation system. When the external calls reach the set threshold, the event queue suspends the current simulation thread to avoid resource overload; after the simulation thread is suspended, the system allocates idle simulation threads from the simulation thread pool to process other events. This mechanism not only avoids the excessive occupation of system resources caused by the backlog of external calls but also ensures that the simulation engine can continue to advance. Through the dynamic allocation and limitation of resources, this technical means effectively balances the call performance and the stability of the simulation engine. When the upper limit of suspended and waiting simulation threads is reached, the simulation thread pool mechanism ensures the dynamic allocation of available simulation threads. When the upper limit is not reached, idle simulation threads will be allocated to process events, avoiding the global efficiency decline caused by the blocking of a single simulation thread. This on-demand allocation method improves the parallel processing ability of the simulation engine, especially showing significant advantages in complex scenarios. Based on the linear data structure of timestamp sorting and event queue management, the time consistency after the completion of asynchronous external calls is guaranteed. In asynchronous calls, some simulation objects wait for the return of external calls, while other objects can continue to run, avoiding the problem of global clock stagnation in the traditional mode. At the same time, after the external call returns, the accurate recovery mechanism at the call point ensures the coherence of the simulation logic, without introducing logical jumps or timing chaos due to asynchronous calls. This application enables the simulation engine to handle multiple external calls and simulation events simultaneously, greatly improving the parallel ability of the simulation. It avoids the blocking problem caused by the long waiting of a single external call in the synchronous call mode and ensures the continuous advancement of the simulation engine. In the case of limited resources, the dynamic threshold and simulation thread pool mechanism optimize resource allocation, maximizing the operating efficiency and stability of the system.

[0059] In one embodiment, in the parallel simulation process, a simulation process is randomly defined as the main process. The main process periodically sends GVT calculation messages, which contain the calculated temporary GVT. Other simulation processes outside the main process receive the GVT calculation messages and mark the process as "in GVT calculation": set the current process status to be in GVT calculation to distinguish it from other non-calculation states; if a simulation process is in the "in GVT calculation" state, then each simulation thread included in it reduces and calculates the minimum timestamp of the messages it sends when sending messages. ;

[0060] Calculate the local GVT, take the minimum value between the local GVT and the temporary GVT in the GVT calculation message as the temporary GVT in the forwarded GVT calculation message and send it to the next process to complete the calculation of the global virtual time in a multi-threaded environment.

[0061] In one embodiment, the process of calculating the local GVT includes:

[0062] When sending events, the minimum timestamp of all sending events in the "in GVT calculation" phase has been reduced and calculated, that is , and all arrived events have been sorted in the event queue, and its minimum timestamp has been reduced to Therefore, the local GVT is .

[0063] In a specific embodiment, GVT calculation in parallel simulation is a global operation, that is, a globally minimum event timestamp still needs to be found during the process of parallel processing events. Assume there are M simulation threads in the simulation, numbered from 0 to M - 1, and thread 0 is the main thread. It periodically sends GVT calculation messages, which contain the calculated GVT value. The initial value of GVT is infinity (which can be implemented as a very large floating-point number). The GVT messages are sequentially passed within all processes and processed according to the Figure 5 shown steps. The local GVT of each thread is the reduced minimum value of the GVTs of all event processing threads among them. For thread t (since one event queue corresponds to one event processing thread, so Figure 5 the superscript j and t are equivalent above), its GVT value is , note that when sending events, the minimum timestamp of all sending events in the "in GVT calculation" phase has been reduced and calculated, that is , and all arrived events have been sorted in the event queue, and its minimum timestamp has been reduced to Among them, further, the local GVT of a thread is the minimum value of the local GVTs of all threads it contains, and the minimum value of the local GVTs of all threads is the local GVT of the process. After that, the minimum value between the local GVT of the process and the temporary GVT in the GVT calculation message is taken as the temporary GVT in the forwarded GVT calculation message and sent to the next process. In this way, after the GVT calculation message traverses all threads and finally reaches thread 0, the GVT of this round is calculated and broadcast to all threads. Among them, to ensure that there is exactly one active thread processing the events in each event queue at any given moment, a queue returned_invoke is set up for each event queue to store the returned external calls. When an external call returns, it is checked whether it is processing an event. If it is not processing an event, the returned event is directly processed; otherwise, it is added to the returned_invoke queue.

[0064] The accurate calculation of the global virtual time (GVT) is crucial for parallel simulation systems, which is directly related to the correctness and coordination of the simulation. This scheme ensures the accurate calculation of GVT through a carefully designed main thread coordination mechanism and a combination of local and global calculation methods. The main process plays a core coordination role in GVT calculation. The randomly selected main process periodically sends GVT calculation messages, which contain the calculated temporary GVT. After receiving this message, other processes mark themselves as "in GVT calculation", and this status mark effectively unifies the rhythm of each process during GVT calculation. In the "in GVT calculation" state, each simulation thread reduces and calculates the minimum timestamp of the messages it sends when sending messages, and this operation collects the time information of each thread during message passing.

[0065] When calculating the local GVT, the system comprehensively considers multiple factors, including the previously recorded event timestamps and the minimum timestamp of the sent messages, etc. By taking the minimum value between the local GVT and the temporary GVT in the GVT calculation message and sending it as the temporary GVT in the forwarded GVT calculation message to the next thread, the system gradually completes the calculation of the global virtual time in a multi-threaded environment. This way of gradually integrating the time information of each thread avoids the problem of missing calculations for simulation objects waiting for external call returns in the asynchronous call mode, thus ensuring the accuracy of GVT calculation.

[0066] Most importantly, the asynchronous external call method set in this application is a prerequisite for the correct calculation of GVT, which is specifically manifested as:

[0067] The mechanism of "processing the events in the event queue in ascending order of the timestamps of the events" ensures the orderliness of event processing. In GVT calculation, each thread needs to accurately process events and record timestamps so that the true occurrence order of events can be reflected when calculating GVT. Through this orderly processing, each thread can perform local GVT calculation and forward GVT calculation messages based on the accurate time order, avoiding GVT calculation errors caused by chaotic event processing.

[0068] When an external call is triggered, a data structure containing information such as timestamps is created and sorted by timestamps, establishing a clear temporal association between the external call and internal event processing. During GVT calculation, this helps accurately determine the impact of the external call on the overall system time advancement, ensuring that the time factor of the external call is taken into account when calculating GVT, so that GVT can truly reflect the global time state of all events (including events related to external calls) in the system.

[0069] Asynchronous calls allow different simulation threads to process events and external calls relatively independently without blocking each other. In GVT calculation, each thread can proceed in order of timestamps in its own event queue and external call processing, while participating in GVT calculation and message passing. This parallelism improves the efficiency of GVT calculation and also ensures that in a multi-threaded environment, GVT can accurately reflect the time advancement of each thread, avoiding GVT calculation stagnation or errors caused by the blocking of a single thread. "If no external call is triggered during the process of a simulation thread processing an event, check whether there is a previously triggered external call that has returned a result, select the event with the smallest timestamp from the returned external calls, and continue to process the event based on the returned result", which ensures that the results of external calls can be correctly processed at the appropriate time. In GVT calculation, the results of external calls may affect the time advancement and state changes of subsequent events. Only by accurately processing these results can the accuracy of the event sequence and time state on which GVT calculation depends be guaranteed, so that GVT can truly reflect the global time progress of the system.

[0070] The entire asynchronous call mechanism ensures the continuity and integrity of event processing. In GVT calculation, the event processing of each thread is the basis of GVT calculation. Only when each thread can correctly process events, external calls and their returned results can it be ensured that the calculation of global virtual time is based on a complete and accurate event chain, thereby obtaining the correct GVT value and enabling the system to achieve accurate time synchronization and coordination in a multi-threaded environment.

[0071] In one embodiment, the timestamp of the event being processed by the current simulation thread serves as the sorting basis for adding the data structure to the linear data structure.

[0072] In one embodiment, the serial number of the external call is used to identify which event triggered the external call, thereby activating this simulation thread to continue processing this event.

[0073] It should be understood that although Figure 2 the steps in the flowchart of Figure 2 are shown in sequence according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless there is a clear indication in this article, there is no strict order limit for the execution of these steps, and these steps can be executed in other orders. Moreover,

[0074] In one embodiment, as Figure 6 shown, a time management device supporting asynchronous external calls is provided, including: an event queue setting module 602, a trigger external call and data structure design module 604, an event processing module 606 for untriggered external calls, and a main thread monitoring module 608, where:

[0075] The event queue setting module 602 is used to start the parallel simulation, start multiple simulation processes to load all simulation objects and start processing events; set multiple event queues in each simulation process, and each event queue is processed by a thread in ascending order of the timestamps of the events in the event queue; there is also a main thread in each simulation process, and each event queue maintains an ordered linear data structure;

[0076] The trigger external call and data structure design module 604 is used to check whether an external call is triggered during the process of the simulation thread processing events. When an external call is triggered by a simulation thread, a data structure is created in the event queue; the data structure includes the current event queue number, the timestamp of the event being processed by the current simulation thread, the saved simulation thread context when the external call is triggered, and the serial number of the external call; the data structure is added to the linear data structure and sorted according to the timestamp. If the length of the linear data structure is greater than the preset upper limit of the number of external calls, the current simulation thread is destroyed. If the length of the linear data structure is not greater than the upper limit of the number of external calls, the simulation thread continues to process the events in the queue;

[0077] The event processing module 606 that does not trigger an external call is used to check whether there is a result returned by a previously triggered external call if no external call is triggered during the process of the simulation thread processing an event. Select the event with the smallest timestamp from the externally called events that have returned results, continue to process the event based on the returned result, and then return to the event queue to retrieve the head event and continue to process subsequent events.

[0078] The main thread listening module 608 is used to listen for the return of an external call. When an external call returns, it is recorded using an ordered linear data structure. Determine the associated event queue according to its call serial number, and judge whether there is an event to be processed in the event queue. If there is an event to be processed in the event queue, add the event to the returned queue; if not, process the relevant event according to the return result of the external call.

[0079] For the specific limitations of a time management device that supports asynchronous external calls, reference can be made to the limitations of a time management method that supports asynchronous external calls in the foregoing text, which will not be elaborated here. Each module in the above-mentioned time management device that supports asynchronous external calls can be implemented in whole or in part by software, hardware, and their combination. The above-mentioned modules can be embedded in the processor of the computer device in hardware form or be independent of it, or can be stored in the memory of the computer device in software form, so as to facilitate the processor to call and execute the operations corresponding to the above-mentioned modules.

[0080] In one embodiment, a computer device is provided. The computer device can be a terminal, and its internal structure diagram can be as Figure 7 shown. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected through a system bus. Among them, the processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The network interface of the computer device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, it realizes a time management method that supports asynchronous external calls. The display screen of the computer device can be a liquid crystal display screen or an electronic ink display screen. The input device of the computer device can be a touch layer covering the display screen, or a button, a trackball, or a touchpad provided on the housing of the computer device, or an external keyboard, touchpad, or mouse, etc.

[0081] Those skilled in the art can understand that Figure 7The structure shown is only a block diagram of some structures related to the solution of this application, and does not constitute a limitation on the computer device to which the solution of this application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine some components, or have different component arrangements.

[0082] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to a memory, storage, database or other medium used in the embodiments provided in this application can include non-volatile and / or volatile memories. Non-volatile memories can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memories can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM), etc.

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

[0084] The above-described embodiments only represent several implementation manners of this application. The description is relatively specific and detailed, but it should not be construed as a limitation on the scope of the invention. It should be noted that for those of ordinary skill in the art, without departing from the concept of this application, several modifications and improvements can be made, and these all belong to the protection scope of this application. Therefore, the protection scope of this application should be subject to the appended claims.

Claims

1. A time management method supporting asynchronous external calls, characterized in that: The method comprises: The parallel simulation starts running, and multiple simulation processes are started to load all simulation objects and start processing events. Multiple event queues are set in each simulation process, and each event queue is processed by a thread in the order of the timestamps of the events in the event queue from small to large. There is also a main thread in each simulation process, and each event queue maintains an ordered linear data structure. During the process of processing an event by a simulation thread, it is checked whether an external call is triggered. When a simulation thread triggers an external call, a data structure is created in the event queue; the data structure includes the current event queue number, the timestamp of the event being processed by the current simulation thread, the simulation thread scene saved when the external call is triggered, and the sequence number of the external call; according to the timestamp of the data structure, the data structure is added to the linear data structure and sorted according to the timestamp, if the length of the linear data structure is greater than the preset upper limit of the number of external calls, the current simulation thread is destroyed, if the length of the linear data structure is not greater than the upper limit of the number of external calls, the simulation thread continues to process the events in the queue; If no external call is triggered during the simulation thread processing of events, check whether the previously triggered external call has returned a result, select the event with the smallest timestamp from the returned external calls, continue to process the event according to the returned result, and then return to the event queue to take out the head event to continue processing subsequent events; The main thread listens for the return of external calls. When the external call returns, it is recorded using an ordered linear data structure, and the associated event queue is determined based on its call sequence number to determine whether there are any processing events in the event queue. If there are any processing events in the event queue, the event is added to the returned queue; if not, the relevant events are processed based on the return result of the external call.

2. The method according to claim 1, characterized in that The method further comprises: In the parallel simulation process, a simulation process is randomly defined as the main process. The main process periodically sends out GVT calculation messages, which contain the calculated temporary GVT. When other simulation processes outside the main process receive the GVT calculation message, they mark the process as "GVT calculation in progress": the current process state is set to GVT calculation in progress to distinguish other non-calculation states; if the simulation process is in the "GVT calculation in progress" state, then each simulation thread contained in it reduces and calculates the minimum timestamp of its sent message when sending a message ; Calculate the local GVT, take the minimum value between the local GVT and the temporary GVT in the GVT calculation message as the temporary GVT in the forwarded GVT calculation message and send it to the next process, completing the calculation of the global virtual time in a multi-threaded environment.

3. The method according to claim 2, characterized in that The process of local GVT calculation includes: When sending an event, the minimum timestamp of all sent events in the "GVT calculation" stage has been reduced and calculated, that is, , and all the arrived events have been sorted in the event queue, and their minimum timestamps have been reduced to Therefore, the local GVT is .

4. The method according to claim 1, characterized in that The timestamp of the event being processed by the current simulation thread is used as the ordering basis for adding the data structure into the linear data structure.

5. The method according to claim 1, characterized in that The sequence number of the external call is used to identify which event triggers the external call, and then activate the simulation thread to continue processing the event.

6. A time management device supporting asynchronous external calls, characterized in that: The device comprises: The event queue setting module is used to start the parallel simulation, start multiple simulation processes to load all simulation objects and start processing events; multiple event queues are set in each simulation process, and each event queue is processed by a thread in the order of the timestamps of the events in the event queue from small to large; there is also a main thread in each simulation process, and each event queue maintains an ordered linear data structure; The module for triggering external calls and designing data structures is used to check whether an external call is triggered during the process of simulating a thread processing an event. When a simulation thread triggers an external call, a data structure is created in the event queue; the data structure includes the current event queue number, the timestamp of the event being processed by the current simulation thread, the simulation thread scene saved when the external call is triggered, and the sequence number of the external call; the data structure is added to the linear data structure according to the timestamp of the data structure and sorted according to the timestamp. If the length of the linear data structure is greater than the preset upper limit of the number of external calls, the current simulation thread is destroyed. If the length of the linear data structure is not greater than the upper limit of the number of external calls, the simulation thread continues to process the events in the queue; The event processing module for untriggered external calls is used to check whether a previously triggered external call has returned a result if no external call is triggered during the simulation thread processing of the event, select the event with the smallest timestamp from the returned external calls, continue to process the event according to the returned result, and then return to the event queue to take out the head event to continue processing subsequent events; The main thread monitoring module is used to monitor the return of external calls. When the external call returns, it is recorded using an ordered linear data structure, and the associated event queue is determined based on its call sequence number to determine whether there are processing events in the event queue. If there are processing events in the event queue, the event is added to the returned queue; if not, the relevant events are processed based on the return result of the external call.

7. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 5 are implemented.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 5 are implemented.

Images