CN112162840B - Coroutine processing and management method based on interrupt reentry mechanism - Google Patents
Coroutine processing and management method based on interrupt reentry mechanism Download PDFInfo
- Publication number
- CN112162840B CN112162840B CN202011047310.0A CN202011047310A CN112162840B CN 112162840 B CN112162840 B CN 112162840B CN 202011047310 A CN202011047310 A CN 202011047310A CN 112162840 B CN112162840 B CN 112162840B
- Authority
- CN
- China
- Prior art keywords
- interrupt
- interface
- coroutine
- cooperative
- program
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 230000007246 mechanism Effects 0.000 title claims abstract description 38
- 238000003672 processing method Methods 0.000 title claims abstract description 16
- 238000007726 management method Methods 0.000 title abstract description 16
- 238000012545 processing Methods 0.000 claims abstract description 50
- 238000000034 method Methods 0.000 claims abstract description 43
- 230000008569 process Effects 0.000 claims abstract description 30
- 230000004044 response Effects 0.000 claims abstract description 22
- 230000009471 action Effects 0.000 claims description 34
- 230000005055 memory storage Effects 0.000 claims description 6
- 238000011161 development Methods 0.000 abstract description 6
- 238000012423 maintenance Methods 0.000 abstract description 2
- 238000010586 diagram Methods 0.000 description 10
- 230000000903 blocking effect Effects 0.000 description 7
- 230000001360 synchronised effect Effects 0.000 description 4
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000013461 design Methods 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000002688 persistence Effects 0.000 description 1
- 238000012805 post-processing Methods 0.000 description 1
- 238000011084 recovery Methods 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4812—Task transfer initiation or dispatching by interrupt, e.g. masked
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/461—Saving or restoring of program or task context
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/52—Program synchronisation; Mutual exclusion, e.g. by means of semaphores
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/5018—Thread allocation
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Executing Machine-Instructions (AREA)
Abstract
The invention discloses a cooperative program processing and management method based on an interrupt reentry mechanism, wherein the cooperative program comprises a main cooperative program and a sub cooperative program, and the interrupt reentry step comprises the following steps: s1: the main cooperative program throws out an interrupt request, and a bottom framework of the main cooperative program responds to the interrupt request and asynchronously sends a task request; s2: switching to an external system processing logic, wherein the main cooperative program releases thread resources; s3: executing reentry of the sub-routine through a callback interface by the task request response, and restoring to the context state during interruption; s4: the sub-cooperative program continues to process the subsequent logic until the execution is finished, and releases the thread resources; or the sub-coroutines are used as new main coroutines to throw out interrupt requests, and the steps S1 to S4 are repeated; in the management method, the coroutine combination is an application, and the application program entry OnProcess () comprises a CallBatch () interface in the processing method. The invention greatly reduces the complexity and workload of development and maintenance of the scheduling program with a large number of parallel branches.
Description
Technical Field
The invention belongs to the technical field of computers, and particularly relates to a cooperative processing and management method based on an interrupt reentry mechanism.
Background
Often, in the development of business applications, it is necessary to develop some schedulers, where many branch flows need to be advanced at the same time, and many branch flows may require a long execution time due to cooperation with the outside, such as the scheduling process shown in fig. 1 (where B, C, D all indicates that a batch task is submitted and waiting for the completion result of the task). The scheduler is developed by adopting a common programming language, and cooperation with the outside is realized in a synchronous blocking mode, so that multi-branch parallel propulsion can be realized only by adopting multithreading, and the working mechanism is shown in fig. 2. It is clear that such a program has the problem that once massive parallel pushing (e.g. more than 1000 parallel branches) is required and many branches have long-time synchronization blocking scenarios, the run-time thread resources are consumed tremendously.
To solve the problem of excessive consumption of thread resources, it is common practice in the industry to program in an asynchronous callback mode, and the working mechanism of the asynchronous callback mode is shown in fig. 3. Obviously, the consumption of thread resources is reduced to the minimum, but the problem of such a program is that a programming model is complex, the programming model does not conform to the thinking habit of people, the maintainability of codes is poor, even the modular development cannot be supported, and a Process method cannot be packaged into a method for returning a completion result when an E action is completed.
In the newer programming languages Go, C #, developers can develop these schedulers based on the coroutine programming model, the working mechanism of which is shown in fig. 4. This working mechanism is almost identical to the program programmed by asynchronous callback at the program model level: all waiting actions result in the coroutine being suspended, and the main thread is terminated after all coroutines are suspended. After receiving the response, the awakened coroutine is continuously pushed in the new thread. Obviously, the program can not only minimize the consumption of thread resources, but also enable the programming model to conform to the thinking habit of people, has good code maintainability, and can support modular development. Unfortunately, the languages supporting the coroutine programming model are few, and the most widely applied languages such as Java, C++ and the like are not supported in the industry at present; even if the languages support the coroutine programming model, most languages generally do not support that the program automatically has some high availability characteristics, and the program can continue to execute after the same scheduling program is run by a machine, and the system is down and restored.
Therefore, there is an urgent need for a cooperative processing and management method based on interrupt reentry mechanism to overcome the above-mentioned drawbacks.
Disclosure of Invention
Aiming at the problems, the invention provides a coroutine processing and management method based on an interrupt reentry mechanism, which adopts a synchronous blocking programming model with better maintainability to develop a scheduling program with a large number of parallel branches, greatly reduces the complexity and workload of the program development and maintenance, can support the program to carry out componentization development, and is not constrained by programming language.
In order to achieve the above purpose, the technical scheme adopted by the invention is as follows:
the coroutine processing method based on the interrupt reentry mechanism comprises a main coroutine and a sub coroutine, wherein the interrupt reentry step comprises the following steps:
s1: the main cooperative program throws out an interrupt request, and a bottom framework of the main cooperative program responds to the interrupt request and asynchronously sends a task request;
s2: switching to an external system processing logic, wherein the main cooperative program releases thread resources;
s3: executing reentry of the sub-routine through a callback interface by the task request response, and restoring to the context state during interruption;
s4: the sub-cooperative program continues to process the subsequent logic until the execution is finished, and releases the thread resources; or the sub-routine throws out an interrupt request as a new main routine, and the above steps S1 to S4 are repeated.
Preferably, step S1 further includes, before the primary cooperative program first throws out the interrupt request, creating an interrupt memory object and registering the interrupt memory object in a memory, where the memory object is used to store an execution result of the non-repeatable action, and the memory is used to store a context of the interrupt;
and step S3, after reentering the sub-cooperative program, executing the sub-cooperative program to an interrupt position, restoring the context to a state when the interrupt is performed, and registering the response result of the task to the memory object.
More preferably, the task is a batch task, and the bottom framework of the main cooperative thread executes the batch task by calling a CallBatch () interface.
More preferably, the CallBatch () interface includes the following steps when first executed:
creating a BatchCall memory object, and registering the BatchCall memory object in a memory storage, wherein an IsInitial identifier of the BatchCall memory object is true at the moment;
executing an Execute () interface of the BatchCall memory object to throw out an interrupt type exception;
capturing the interrupt type exception by a calling party, and executing an ExecuteAfteterInterconnection () interface of the BatchCall memory object;
the ExecuteAfter internation () interface calls the OnExecuteAfter internation () interface of the BatchCall memory object, asynchronously sends a request of a batch processing task and registers a callback interface in a memory;
after the action is executed, the isInitial identifier of the BatchCall memory object is set to false, and the program execution is ended, so that the thread resource is released.
More preferably, the task answer is switched to the main cooperative program through a callback interface, comprising the following steps:
the bottom layer framework uses a new thread to call a callback interface HandleResponse (), and transmits a task response to the callback interface HandleResponse ();
the callback interface HandleResponse () calls a Resume () interface, and the Resume () calls an OnProcess () interface to restart the execution of the main co-program processing logic;
when the main cooperative program executes the call () interface again, checking the patchcall memory object registered in the memory storage, wherein the isInitial identifier of the patchcall memory object is false at the moment, the Execute () interface is not executed any more, and the task response is registered in the patchcall memory object, so that the task response can be acquired from the patchcall memory object to continue the subsequent processing.
More preferably, the task response content is stored in the BatchCall memory object.
The coroutine management method based on the interrupt reentry mechanism is characterized in that the coroutine processing method based on the interrupt reentry mechanism is utilized, the coroutine is combined into an application, the coroutine comprises a coroutine identifier, an interrupt identifier isInteruped and a memory, the application operation comprises the calling of a primary starting processing interface Process () and a multiple reentry processing interface result (), and also comprises an application program inlet OnProcess (), and both the starting processing interface Process () and the reentry processing interface result () execute processing logic by calling the application program inlet OnProcess (), and the application program inlet OnProcess () comprises the CallBatch () interface; the application entry OnProcess () is invoked by looping through the coroutine set of the application before invoking the application entry OnProcess ().
Preferably, the loop-through application's coroutine set comprises the steps of:
executing a while circulation traversal cooperative path set, setting a cooperative path as a current cooperative path when acquiring one cooperative path through traversal, checking an interrupt identifier isInterconnected of the current cooperative path, if the interrupt identifier isInterconnected is true, indicating that the interrupt is in an interrupt state, and continuing to traverse the next cooperative path by the while circulation; if the interrupt identifier isIntermounted is false, indicating that the interrupt is in a non-interrupt state, and setting all the isInitial identifiers memorized in the memory of the current cooperative program as false;
invoking an OnProcess () interface to execute application processing logic, capturing an interrupt by a while loop and executing an ExecuteAfter Interconnection () interface when the application executes the interrupt, setting an IsInterconnected identifier of the current cooperative program as true, ending execution, and continuing traversing the next cooperative program by the while loop; if the application is executed from the OnProcess () interface and the interrupt exception is not thrown, ending the current coroutine execution, deleting the current coroutine from the coroutine set of the application by the while loop, and continuing traversing the next coroutine by the while loop;
repeating the steps until the while cycle traversal is finished.
More preferably, the thread will create a default coroutine application thread object when it starts executing for the first time by starting processing interface Process (), and the interrupt identifier isInterrupted of the coroutine application thread object is false.
More preferably, the application entry OnProcess () includes a Fork () interface, and the first time the Fork () interface is executed, the method includes the steps of:
newly generating a Forkmemory object, and registering the Forkmemory object into a memory of the current cooperative program, wherein an isInitial identifier of the Forkmemory object is true at the moment;
generating a plurality of new coroutines on the basis of the current coroutines according to the number of the input coroutines, wherein the new coroutines are consistent with the memory of the current coroutines, the interrupt identifier isInterconnected of the new coroutines is false, the new coroutines are registered into an applied coroutine set, and the current coroutines and the identifiers of all newly generated coroutines are stored in a ForkMemory object;
when reentrant is executed, a ForkMemory object is obtained from the memory of the original coroutine, at this time, the isInitial identifier of the ForkMemory object is false, the coroutine is not newly created, and the application can obtain the coroutine identifier generated previously from the ForkMemory object.
More preferably, the application program entry OnProcess () further includes a Merge () interface, the application transmits a coroutine identifier set generated by the form () interface to the Merge () interface, and the Merge () interface is executed as follows:
executing a while circulation traversal cooperative path identifier set, when one cooperative path identifier is acquired through traversal, setting the cooperative path identifier as a current identifier, and if the traversed identifier is the same as the current cooperative path identifier, continuing to traverse the next cooperative path identifier by the while circulation; if the traversed identifier is different from the current coroutine identifier, traversing the coroutine set of the application by the while loop;
if the coroutine consistent with the current identifier exists in the coroutine set of the application, deleting the current coroutine from the coroutine set, and throwing out an interrupt exception;
if there is no coroutine consistent with the current identifier in the coroutine set of the application, the Merge () interface returns true normally.
Compared with the prior art, the invention has the beneficial effects that:
1. the cooperative processing and management method based on the interrupt reentry mechanism enables a developer to develop a scheduling program with a large number of parallel branches by adopting a synchronous blocking programming model with better maintainability, greatly reduces the complexity and workload of developing and maintaining the program, and can support the modular development of the program.
2. The coroutine processing and management method based on the interrupt reentry mechanism ensures that the synchronous blocking design operation of the program is automatically converted into the asynchronous callback/non-blocking mode for execution, and ensures that the consumption of thread resources is reduced to the minimum.
3. The program state is automatically and permanently maintained at the moment of thread termination, and is automatically recovered when a new thread catcher continues to execute, so that the high availability characteristics of the replaceable machine operation and the continuous execution after the downtime recovery are obtained.
4. The coroutine processing and management method based on the interrupt reentry mechanism is not limited by programming languages, and supports C, C ++, java and other languages.
Drawings
Fig. 1 is a schematic diagram of a scheduling process described in the background art.
Fig. 2 is a schematic diagram of a system operating mechanism described in the background.
Fig. 3 is a schematic diagram of another system operating mechanism described in the background.
Fig. 4 is a schematic diagram of another system operating mechanism described in the background.
FIG. 5 is a schematic diagram of an operation mechanism of a coroutine processing method based on an interrupt reentry mechanism according to the present invention.
Fig. 6 is a view of a protocol Cheng Anli described in example two.
Fig. 7 is a schematic diagram of a protocol case operation process according to the second embodiment.
Fig. 8 is a protocol case execution process described in embodiment two.
Fig. 9 is a schematic diagram of a protocol case operation process according to the second embodiment.
Fig. 10 is a schematic diagram of a protocol case operation process according to the second embodiment.
FIG. 11 is a schematic diagram illustrating an operation mechanism of a coroutine management method based on an interrupt reentry mechanism according to the present invention.
FIG. 12 is a schematic diagram of another working mechanism of a coroutine management method based on an interrupt reentry mechanism according to the present invention.
Detailed Description
For a better understanding of the present invention, the content of the present invention will be further elucidated with reference to the drawings and examples, but the invention is not limited to the examples described below.
Example 1
A cooperative program processing method based on an interrupt reentry mechanism includes a main cooperative program and a sub cooperative program, wherein the interrupt reentry step includes:
s1: the main cooperative program throws out an interrupt request, and a bottom framework of the main cooperative program responds to the interrupt request and asynchronously sends a task request;
s2: switching to an external system processing logic, and releasing thread resources by a main cooperative program;
s3: executing re-entry sub-cooperation through a callback interface in response to the task request, and restoring to the context state during interruption;
s4: the sub-cooperative program continues to process the subsequent logic until the execution is finished, and releases the thread resources; or the sub-routine throws out an interrupt request as a new main routine, and the above steps S1 to S4 are repeated.
As shown in FIG. 5, the main routine completes the PartA action to throw out the interrupt request, the underlying framework captures the interrupt, immediately executes the action and releases the thread resource, then uses the new thread to jump to the previous interrupt in the callback function, and the context is restored to the state of the previous interrupt, the result information of the asynchronous non-blocking interface executing the action is obtained, and the subsequent processing is continued. In this process, there is a repetition of the PartA action.
As can be seen in FIG. 5, the re-entry causes the same action to be repeatedly performed, while some actions do not allow for re-entry, e.g., adding an amount to the account. Therefore, in some cases, it is necessary to ensure that the nth action performed at the time of the reentry is completely identical to the nth action performed at the time of the execution of the previous execution of the reentry in both input and output, and no new influence is generated on the external environment (for example, the database, the file system, the environment information of the present system, the environment information and data of the external system, etc.).
Therefore, step S1 further includes, before the primary cooperative program first throws out the interrupt request, creating an interrupt memory object and registering the interrupt memory object in the memory, where the memory object is used for storing the execution result of the unrepeatable action, and the memory is used for storing the interrupt context. Step S3 also comprises, after re-entering the sub-routine, executing the sub-routine to the interrupt and restoring the context to the state at the time of interrupt, and registering the response result of the task to the memory object. The context here refers to all memory objects generated in this process.
Taking a batch task as an example, the bottom framework of the main cooperative program executes the batch task by calling a CallBatch () interface.
The first execution of the CallBatch () interface includes the steps of:
1. creating a BatchCall memory object, and registering the BatchCall memory object in a memory storage, wherein an isInitial identifier of the BatchCall memory object is true at the moment;
2. executing an Execute () interface of the BatchCall memory object to throw out an interrupt type exception;
3. capturing interrupt type exception by a calling party, and executing an ExecuteAfterInterconnection () interface of the BatchCall memory object;
4. the ExecuteAfter interface () interface calls the OnExecuteAfter interface () interface of the BatchCall memory object, asynchronously sends the request of the batch processing task and registers a callback interface in the memory;
5. after the execution of the action is completed, the isInitial identifier of the BatchCall memory object is set to false, and the execution of the program is completed, so that the thread resource is released.
The batch processing task is switched to the main cooperative program through the callback interface, and the method comprises the following steps of:
1. the bottom layer framework uses a new thread to call up a callback interface HandleResponse (), and transmits a task response to the callback interface HandleResponse ();
2. the callback interface calls a Resume () interface, and the Resume () interface calls an OnProcess () interface to restart executing the main cooperative processing logic;
3. when the main routine is executed to the Call batch () interface again, the BatchCall memory object registered in the memory is checked, at this time, the isInitial of the BatchCall memory object is marked as false, the Execute () interface is not executed any more, and the task response is registered in the BatchCall memory object, so that the task response can be acquired from the BatchCall memory object and the subsequent processing can be continued.
The task response content is stored in the BatchCall memory object.
Example two
An application embodiment of a coroutine processing method based on an interrupt reentry mechanism runs a coroutine as shown in fig. 6. The round box of the identifier beginning with F represents the Fork action (non-repeatable during re-entry), and the round box beginning with M represents the Merge action (repeatable during re-entry). B. G, H is an action which cannot be repeatedly executed when the user is the user, A, C, E is an action which can be repeatedly executed when the user is the user, and D, F, I is an interrupt action.
The code implementation is as follows:
the complete operation process is as follows:
as shown in FIG. 7, the application initially executes based on the T1 coroutine, executing the F0 action Fork to go out the T11, T12 coroutine. When executing the F1 action Fork out of the T111 cooperative stroke based on the T11 cooperative stroke, actions of T1, T11 and T12 before interruption and all actions of T111 are completed in one thread. The actions of F0 in T11, F0 in T12, and F0 and B, F1 in T111 are not repeatedly executed at the time of current thread and weight.
As shown in fig. 8, the D action reply is based on T11 protocol Cheng Chongru back until the T11 protocol is terminated (or interrupted again), noting that this process is running on a new thread. In T11, the actions F0, B, F1, and D are not repeatedly performed during reentry.
As shown in fig. 9, the F action reply is based on the T1 protocol Cheng Chongru back until the T1 protocol is terminated (or again interrupted). Wherein, in T1, the actions of F0 and F are not repeatedly executed when the actions are repeated.
As shown in fig. 10, the I action reply back is based on the T12 protocol Cheng Chongru until the T12 protocol is terminated (or again interrupted). Wherein, the actions of F0 and G, H, I in T12 are not repeatedly executed when the actions are repeated.
Example III
As shown in fig. 11, in a coroutine management method based on an interrupt reentrant mechanism, the coroutine described in the first embodiment is combined into an application, where the coroutine includes a coroutine identifier, an interrupt identifier isInteruped and a memory, the application running includes a call of a start processing interface Process () and a multiple reentrant processing interface Resume (), and also includes an application entry OnProcess (), where the start processing interface Process () and the reentrant processing interface Resume () execute processing logic by calling the application entry OnProcess (), and the application entry OnProcess () includes a CallBatch () interface described in the first embodiment; the application entry OnProcess () is invoked by looping through the coroutine set of the application before invoking the application entry OnProcess ().
The loop-through application's coroutine set includes the steps of:
1. executing a while circulation traversal routine set, setting a cooperative routine as a current cooperative routine when one cooperative routine is acquired through traversal, checking an interrupt identifier isInterconnected of the current cooperative routine, if the interrupt identifier isInterconnected is true, indicating that the current cooperative routine is in an interrupt state, and continuing to traverse the next cooperative routine by the while circulation; if the interrupt flag isInterconnected is false, indicating that the interrupt is in a non-interrupt state, setting all the isInitial flags memorized in the memory of the current cooperative program to false.
2. Invoking an OnProcess () interface to execute application processing logic, capturing an interrupt by a while loop and executing an ExecuteAfter Interconnection () interface when the application executes the interrupt, setting an IsInterconnected identifier of the current cooperative program as true, ending execution, and continuing traversing the next cooperative program by the while loop; if the application is executed from the OnProcess () interface and the interrupt exception is not thrown, the current coroutine execution is ended, the while loop deletes the current coroutine from the coroutine set of the application, and the while loop continues to traverse the next coroutine. After capturing an interrupt exception by the while loop, finding that the coroutine corresponding to the interrupt exception has been deleted, the interrupt post-processing logic interface executeAfteterInterconnection () is not executed any more, but the next uninterrupted coroutine is continuously traversed and executed.
3. Repeating the steps until the while cycle traversal is finished.
When the thread starts to execute for the first time through the start processing interface Process (), a default cooperative thread object is created, and an interrupt identifier isInterrupted of the cooperative thread object is false. The application starts to execute based on the coroutine.
As shown in fig. 12, the application entry OnProcess () includes a Fork () interface, and by calling the Fork () interface provided by the bottom framework, the application can generate multiple coprocesses to implement multi-branch parallel propulsion. The first time the Fork () interface is executed, it includes the following steps:
1. newly generating a Forkmemory object, and registering the Forkmemory object into a memory of the current cooperative program, wherein an isInitial identifier of the Forkmemory object is true at the moment;
2. generating a plurality of new coroutines on the basis of the current coroutines according to the number of the input coroutines, wherein the new coroutines are consistent with the memory of the current coroutines, the interrupt identifier isInterconnected of the new coroutines is false, the new coroutines are registered into a coroutine set of the application, and the identifiers of the current coroutines and all newly generated coroutines are stored in a ForkMemory object;
3. when reentrant is executed, a ForkMemory object is obtained from the original cooperative program, at this time, the isInitial identifier of the ForkMemory object is false, the cooperative program is not newly created, and the application can obtain the previously generated cooperative program identifier from the ForkMemory object.
The application program entry OnProcess () also comprises a Merge () interface, the Merge () interface is matched with the Fork () interface, and the Fork () interface transmits the generated identifiers of a plurality of coroutines to the Merge () interface; the execution steps of the Merge () interface are as follows:
1. executing a while circulation traversal cooperative path identifier set, when one cooperative path identifier is acquired through traversal, setting the cooperative path identifier as a current identifier, and if the traversed identifier is the same as the current cooperative path identifier, continuing to traverse the next cooperative path identifier by the while circulation; if the traversed identity is not the same as the identity of the current coroutine, the while loop will traverse the coroutine set of the application. The Merge () interface here internally includes two layers of control logic.
2. If the coroutines consistent with the current identification exist in the coroutine set of the application, the fact that other coroutines are not executed is indicated, the current coroutines are deleted from the coroutine set, and interrupt exception is thrown out.
If the cooperative program set of the application does not have the cooperative program consistent with the current identifier, the while loop continues to traverse the next cooperative program identifier of the cooperative program identifier set, and thus the process is repeated, and finally, if the identifiers of other cooperative programs except the current cooperative program in the cooperative program set of the application do not exist in the cooperative program identifier set, the execution of all cooperative programs is finished, the true () interface normally returns true, and the application can continue to execute subsequent logic on the basis of the current cooperative program, so that one cooperative program propulsion is realized.
By calling the Merge () interface provided by the underlying framework, multiple coroutines of the application (all after execution to the Merge point) can be "merged" into one coroutine to achieve a branch advance. When some (non-last) co-program is executed to the Merge point and other co-programs which are not executed are still existed, the application will continue to interrupt, the bottom layer framework clears the co-program, and the last co-program will continue to process after being executed to the Merge point.
Once the application is running, the state of the application object is serialized into a storable format (such as XML messages, binary data …) and persisted into a storage device (such as database, file …) once the application is interrupted (freeing up the thread resources), and when an external system response arrives, the infrastructure obtains the persisted application state from the storage device and deserializes it into the application object for processing when a new thread is launched.
Based on state persistence, the application can easily realize the operation of changing machine and continue to execute after the downtime is recovered, namely when the external system answer is loaded on any available system or the system downtime is recovered, the external system answer arrives, the new thread can be used for reentering through an answer message processing application, and the bottom framework then obtains the application state from the storage equipment and inversely sequences the application state into an application object to finish the subsequent processing.
Example IV
The first embodiment of the invention provides a cooperative processing method based on an interrupt reentry mechanism and the third embodiment of the invention provides a cooperative management method based on an interrupt reentry mechanism, which are used for processing daily batch generation wage transaction cases.
The transaction processing flow comprises 3 steps: file reading and warehousing generation wage result file generation. Where the size of the data to be processed in the file may be large (tens of thousands to millions of strokes are not equal). In order to improve transaction processing performance on the basis of efficient utilization of thread resources, the 3 steps are arranged in a batch generation wage scheduling application (based on scheduling system execution), when the step 2 is executed, data in a file is partitioned by taking 1000 strokes as a unit, each block corresponds to one batch generation wage batch processing task (based on batch processing system execution), so that all batch processing task requests can be distributed into a batch processing system cluster to be executed and interrupted to release the thread resources by utilizing a batch management framework and a CallBatch interface, and a new thread reentry processing is reused when the batch processing system answers, until the processing is completed or interrupted again.
Examples of codes are as follows:
/>
/>
/>
/>
/>
it will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The present embodiments are, therefore, to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein.
Claims (10)
1. The coroutine processing method based on the interrupt reentry mechanism is characterized in that the coroutine comprises a main coroutine and a sub coroutine, and the interrupt reentry step comprises the following steps:
s1: the main cooperative program throws out an interrupt request, and a bottom framework of the main cooperative program responds to the interrupt request and asynchronously sends a task request;
s2: switching to an external system processing logic, wherein the main cooperative program releases thread resources;
s3: executing reentry of the sub-routine through a callback interface by the task request response, and restoring to the context state during interruption;
s4: the sub-cooperative program continues to process the subsequent logic until the execution is finished, and releases the thread resources; or the sub-routine throws out an interrupt request as a new main routine, and the above steps S1 to S4 are repeated.
2. The method according to claim 1, wherein step S1 further comprises, before the primary cooperative program first throws out the interrupt request, creating an interrupt memory object and registering the interrupt memory object in a memory, where the memory object is used to store an execution result of the non-repeatable action, and the memory is used to store a context of the interrupt;
and step S3, after reentering the sub-cooperative program, executing the sub-cooperative program to an interrupt position, restoring the context to a state when the interrupt is performed, and registering the response result of the task to the memory object.
3. The method for cooperative processing based on interrupt reentry mechanism as recited in claim 2, wherein the task is a batch task, and the bottom framework of the main cooperative executes the batch task by calling a CallBatch () interface.
4. The coroutine processing method based on the interrupt reentry mechanism as claimed in claim 3, wherein the CallBatch () interface is executed for the first time, comprising the steps of: creating a BatchCall memory object, and registering the BatchCall memory object in a memory storage, wherein an IsInitial identifier of the BatchCall memory object is true at the moment;
executing an Execute () interface of the BatchCall memory object to throw out an interrupt type exception;
capturing the interrupt type exception by a calling party, and executing an ExecuteAfteterInterconnection () interface of the BatchCall memory object;
the ExecuteAfter internation () interface calls the OnExecuteAfter internation () interface of the BatchCall memory object, asynchronously sends a request of a batch processing task and registers a callback interface in a memory;
after the action is executed, the isInitial identifier of the BatchCall memory object is set to false, and the program execution is ended, so that the thread resource is released.
5. The method for processing the main protocol based on the interrupt reentry mechanism as claimed in claim 4, wherein the task response is switched to the main protocol through a callback interface, comprising the steps of:
the bottom layer framework uses a new thread to call a callback interface HandleResponse (), and transmits a task response to the callback interface HandleResponse ();
the callback interface HandleResponse () calls a Resume () interface, and the Resume () calls an OnProcess () interface to restart the execution of the main co-program processing logic;
when the main cooperative program executes the call () interface again, checking the patchcall memory object registered in the memory storage, wherein the isInitial identifier of the patchcall memory object is false at the moment, the Execute () interface is not executed any more, and the task response is registered in the patchcall memory object, so that the task response can be acquired from the patchcall memory object to continue the subsequent processing.
6. The method for coroutine processing based on interrupt reentry mechanism as claimed in claim 5, wherein task response contents are stored in the BatchCall memory object.
7. A method for managing a co-program based on an interrupt reentry mechanism, characterized in that, the method for processing a co-program based on an interrupt reentry mechanism according to any one of claims 3-6 is utilized, the co-program is an application, the co-program includes a co-program identifier, an interrupt identifier isInteruped and a memory, the application running includes a call of a start processing interface Process () and a multiple reentry processing interface result () and also includes an application entry on Process (), the start processing interface Process () and the reentry processing interface result () each execute processing logic by calling the application entry on Process (), and the application entry on Process () includes the CallBatch () interface; the application entry OnProcess () is invoked by looping through the coroutine set of the application before invoking the application entry OnProcess ().
8. The method for coroutine management based on interrupt reentry mechanism as recited in claim 7, wherein the loop traversing the coroutine set of the application comprises the steps of:
executing a while circulation traversal cooperative path set, setting a cooperative path as a current cooperative path when acquiring one cooperative path through traversal, checking an interrupt identifier isInterconnected of the current cooperative path, if the interrupt identifier isInterconnected is true, indicating that the interrupt is in an interrupt state, and continuing to traverse the next cooperative path by the while circulation; if the interrupt identifier isIntermounted is false, indicating that the interrupt is in a non-interrupt state, and setting all the isInitial identifiers memorized in the memory of the current cooperative program as false;
invoking an OnProcess () interface to execute application processing logic, capturing an interrupt by a while loop and executing an ExecuteAfterInterconnection () interface when the application executes the interrupt, setting an isInterconnected identifier of the current cooperative program as true, ending execution, and continuing traversing the next cooperative program by the while loop; if the application is executed from the OnProcess () interface and the interrupt exception is not thrown, ending the current coroutine execution, deleting the current coroutine from the coroutine set of the application by the while loop, and continuing traversing the next coroutine by the while loop;
repeating the steps until the while cycle traversal is finished.
9. The method according to claim 8, wherein a default coroutine application thread object is created when the thread starts executing for the first time by starting to Process interface Process (), and an interrupt identifier isInterconnected of the coroutine application thread object is false.
10. The method for coroutine management according to claim 8, wherein the application entry OnProcess () includes a Fork () interface, and the first time the Fork () interface is executed includes the steps of:
newly generating a Forkmemory object, and registering the Forkmemory object into a memory of the current cooperative program, wherein an isInitial identifier of the Forkmemory object is true at the moment;
generating a plurality of new coroutines on the basis of the current coroutines according to the number of the input coroutines, wherein the new coroutines are consistent with the memory of the current coroutines, the interrupt identifier isInterconnected of the new coroutines is false, the new coroutines are registered into an applied coroutine set, and the current coroutines and the identifiers of all newly generated coroutines are stored in a ForkMemory object;
when reentrant is executed, a ForkMemory object is obtained from a memory storage of an original cooperative program, at the moment, an isInitial identifier of the ForkMemory object is false, the cooperative program is not newly created, and an application can obtain a previously generated cooperative program identifier from the ForkMemory object;
the application program entry OnProcess () further comprises a Merge () interface, the application transmits a coroutine identifier set generated by the Fork () interface to the Merge () interface, and the Merge () interface is executed as follows:
executing a while circulation traversal cooperative path identifier set, when one cooperative path identifier is acquired through traversal, setting the cooperative path identifier as a current identifier, and if the traversed identifier is the same as the current cooperative path identifier, continuing to traverse the next cooperative path identifier by the while circulation; if the traversed identifier is different from the current coroutine identifier, traversing the coroutine set of the application by the while loop;
if the coroutine consistent with the current identifier exists in the coroutine set of the application, deleting the current coroutine from the coroutine set, and throwing out an interrupt exception;
if there is no coroutine consistent with the current identifier in the coroutine set of the application, the Merge () interface returns true normally.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011047310.0A CN112162840B (en) | 2020-09-29 | 2020-09-29 | Coroutine processing and management method based on interrupt reentry mechanism |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011047310.0A CN112162840B (en) | 2020-09-29 | 2020-09-29 | Coroutine processing and management method based on interrupt reentry mechanism |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112162840A CN112162840A (en) | 2021-01-01 |
| CN112162840B true CN112162840B (en) | 2024-03-08 |
Family
ID=73862088
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011047310.0A Active CN112162840B (en) | 2020-09-29 | 2020-09-29 | Coroutine processing and management method based on interrupt reentry mechanism |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112162840B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN114756357B (en) * | 2022-06-14 | 2022-10-14 | 浙江保融科技股份有限公司 | Non-blocking distributed planned task scheduling method based on JVM (Java virtual machine) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5276879A (en) * | 1989-10-31 | 1994-01-04 | Hewlett-Packard Company | Portable, resource sharing file server using co-routines |
| CN109885386A (en) * | 2019-01-03 | 2019-06-14 | 北京潘达互娱科技有限公司 | A kind of method, apparatus and electronic equipment of multitask execution |
| CN110247984A (en) * | 2019-06-27 | 2019-09-17 | 腾讯科技（深圳）有限公司 | Method for processing business, device and storage medium |
| CN111190569A (en) * | 2019-12-30 | 2020-05-22 | 中国科学技术大学 | Homomorphic encryption unloading method based on Intel QAT |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US9516100B2 (en) * | 2014-02-05 | 2016-12-06 | Travis T. Wilson | Method and system for executing third-party agent code in a data processing system |
-
2020
- 2020-09-29 CN CN202011047310.0A patent/CN112162840B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5276879A (en) * | 1989-10-31 | 1994-01-04 | Hewlett-Packard Company | Portable, resource sharing file server using co-routines |
| CN109885386A (en) * | 2019-01-03 | 2019-06-14 | 北京潘达互娱科技有限公司 | A kind of method, apparatus and electronic equipment of multitask execution |
| CN110247984A (en) * | 2019-06-27 | 2019-09-17 | 腾讯科技（深圳）有限公司 | Method for processing business, device and storage medium |
| CN111190569A (en) * | 2019-12-30 | 2020-05-22 | 中国科学技术大学 | Homomorphic encryption unloading method based on Intel QAT |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112162840A (en) | 2021-01-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US20120246651A1 (en) | System and method for supporting batch job management in a distributed transaction system | |
| CN110795254A (en) | Method for processing high-concurrency IO based on PHP | |
| US20200310828A1 (en) | Method, function manager and arrangement for handling function calls | |
| CN112162840B (en) | Coroutine processing and management method based on interrupt reentry mechanism | |
| CN113791889B (en) | Method for deploying learning model based on multistage polling queue controller | |
| CN111651279A (en) | Method and system for processing business process | |
| CN111338775B (en) | Method and equipment for executing timing task | |
| CN111597035B (en) | Simulation engine time propulsion method and system based on multithreading | |
| CN112948096A (en) | Batch scheduling method, device and equipment | |
| CN112416414A (en) | Micro-service architecture containerized lightweight workflow system based on state machine | |
| CN113296898B (en) | Asynchronous task processing method and device, electronic equipment and storage medium | |
| CN115114022A (en) | Method, system, device and medium for using GPU resources | |
| US10713085B2 (en) | Asynchronous sequential processing execution | |
| CN112559148A (en) | Execution method, execution device and execution system of ordered tasks | |
| CN112367205A (en) | Processing method and scheduling system for HTTP scheduling request | |
| CN102681881A (en) | Cross-computer scheduling method and system thereof | |
| CN110879747B (en) | Resource management method and device | |
| CN108228362B (en) | Compatible method, module and channel system of VxWorks system | |
| CN115220879A (en) | Asynchronous calling method and device, computer equipment and readable storage medium | |
| CN117251277A (en) | Method, device, equipment, medium and program product for executing task instance | |
| CN118227455A (en) | Test method and test architecture | |
| CN115481156A (en) | Data processing method, device, equipment and medium | |
| CN115827331A (en) | Processing method | |
| CN117971378A (en) | Workflow execution method, workflow execution device, electronic equipment and storage medium | |
| CN116010053A (en) | Task information pushing method and device, storage medium and electronic device |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |