CN117519947A - Coroutine monitoring method, device, equipment and readable storage medium - Google Patents
Coroutine monitoring method, device, equipment and readable storage medium Download PDFInfo
- Publication number
- CN117519947A CN117519947A CN202311693341.7A CN202311693341A CN117519947A CN 117519947 A CN117519947 A CN 117519947A CN 202311693341 A CN202311693341 A CN 202311693341A CN 117519947 A CN117519947 A CN 117519947A
- Authority
- CN
- China
- Prior art keywords
- task
- thread
- monitoring
- coroutine
- time
- 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.)
- Pending
Links
- 238000012544 monitoring process Methods 0.000 title claims abstract description 146
- 238000000034 method Methods 0.000 title claims abstract description 51
- 238000012545 processing Methods 0.000 claims abstract description 25
- 238000012806 monitoring device Methods 0.000 claims abstract description 16
- 230000008569 process Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 6
- 238000004891 communication Methods 0.000 description 5
- 230000006870 function Effects 0.000 description 3
- 230000007246 mechanism Effects 0.000 description 3
- 238000013461 design Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000009471 action Effects 0.000 description 1
- 230000000903 blocking effect Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000009792 diffusion process Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 238000011835 investigation Methods 0.000 description 1
- 230000007958 sleep Effects 0.000 description 1
- 230000001360 synchronised effect Effects 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/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
-
- 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
- G06F2209/00—Indexing scheme relating to G06F9/00
- G06F2209/50—Indexing scheme relating to G06F9/50
- G06F2209/508—Monitor
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application provides a coroutine monitoring method, a coroutine monitoring device, coroutine monitoring equipment and a readable storage medium, wherein the coroutine monitoring method comprises the following steps: monitoring the running time of the current task of each cooperative distance through a monitoring thread; if the running time of the current task of a certain cooperative program is longer than the preset task time, creating a temporary thread through the monitoring thread, wherein the temporary thread is used for executing timeout processing for the task and automatically destroying the task after the execution is finished. In the method, the monitoring period is not influenced by the cooperative program scheduling and the overtime processing, the task operation duration in the cooperative program is continuously and stably monitored, and the overtime processing is timely executed for the overtime task, so that the normal operation of the cooperative program is ensured.
Description
Technical Field
The present invention relates to the field of coroutine scheduling technologies, and in particular, to a coroutine monitoring method, device, equipment, and readable storage medium.
Background
The coroutine is a user-state lightweight thread, a scheduler obtains tasks from a plurality of task queues to execute according to a certain scheduling strategy in the coroutine, and after one task is completed, the scheduler obtains new tasks from the task queues to execute. Based on the principle, the kernel mode is not required to be switched when the task is switched, and the natural lock-free mechanism can be realized by putting the tasks with the same operation resource into the same task queue, and the code can be written in a synchronous mode while the asynchronous operation mechanism is maintained, so that high concurrency is realized, and the development period is shortened.
However, in practical application, there is often a problem that a task is not scheduled due to a task mechanism or a program error, and the running time is too long or even blocked, so that other tasks cannot be scheduled, and a scheduler needs to wait for the task being executed to complete and then process a fault due to its implementation principle, if blocking occurs, the fault is diffused, and then the scheduling of the whole cooperative program is blocked, and even service is unavailable when serious.
Disclosure of Invention
The application provides a coroutine monitoring method, a coroutine monitoring device, coroutine monitoring equipment and a readable storage medium, which can solve the technical problem that the normal operation of a coroutine is influenced by overlong task operation time in coroutine in the prior art.
In a first aspect, an embodiment of the present application provides a cooperative journey monitoring method, where the cooperative journey monitoring method includes:
monitoring the running time of the current task of each cooperative distance through a monitoring thread;
if the running time of the current task of a certain cooperative program is longer than the preset task time, creating a temporary thread through the monitoring thread, wherein the temporary thread is used for executing timeout processing for the task and automatically destroying the task after the execution is finished.
Further, in an embodiment, after the step of creating the temporary thread by the monitoring thread, the method further includes:
monitoring the operation time of the temporary thread through a monitoring thread;
if the operation duration of the temporary thread is longer than the preset thread duration, destroying the temporary thread through the monitoring thread.
Further, in an embodiment, if the running duration of the current task of a certain coroutine is greater than the preset task duration, the step of creating the temporary thread by the monitoring thread includes:
if the running time of the current task of a certain coroutine is longer than the first task time, a first temporary thread is created through the monitoring thread, wherein the first temporary thread is used for marking the coroutine as an unavailable state.
Further, in an embodiment, if the running duration of the current task of a certain coroutine is greater than the preset task duration, the step of creating the temporary thread by the monitoring thread further includes:
if the running time of the current task of a certain cooperative program is longer than the second task time, a second temporary thread is created through the monitoring thread, wherein the second task time is shorter than the first task time, the second temporary thread is used for writing the running starting time, the task number, the running time and the call stack of the task and the dispatcher information of the cooperative program into a log, and outputting an alarm prompt.
Further, in an embodiment, if the running duration of the current task of a certain coroutine is greater than the preset task duration, the step of creating the temporary thread by the monitoring thread further includes:
if the running time of the current task of a certain cooperative distance is longer than the third task time, creating a third temporary thread through the monitoring thread, wherein the third task time is shorter than the second task time, and the third temporary thread is used for writing the third task time, the running starting time of the task, the task number and the running time into a log.
Further, in an embodiment, each co-program writes scheduler information into the monitoring thread in an initialization phase, and writes a running start time and a task number of a corresponding task into the monitoring thread when each task is scheduled.
Further, in an embodiment, each co-program writes the running start time of the corresponding task into the monitoring thread when each task is scheduled;
for each coroutine, the monitoring thread determines the running time of the current task of the corresponding coroutine according to the current time and the latest written running starting time.
In a second aspect, an embodiment of the present application further provides a cooperative distance monitoring device, where the cooperative distance monitoring device includes:
the monitoring module is used for monitoring the running time of the current task of each protocol through the monitoring thread;
the creating module is used for creating a temporary thread through the monitoring thread if the running time of the current task of a certain cooperative program is longer than the preset task time, wherein the temporary thread is used for executing timeout processing on the task and is automatically destroyed after the execution is finished.
In a third aspect, an embodiment of the present application further provides a co-program monitoring device, where the co-program monitoring device includes a processor, a memory, and a co-program monitoring program stored in the memory and executable by the processor, where the co-program monitoring program, when executed by the processor, implements the steps of the co-program monitoring method described above.
In a fourth aspect, an embodiment of the present application further provides a readable storage medium, where a coroutine monitoring program is stored on the readable storage medium, where the coroutine monitoring program, when executed by a processor, implements the steps of the coroutine monitoring method described above.
In the method, the operation duration of the current task of each cooperative program is monitored through the monitoring thread, compared with the monitoring implemented in the cooperative program, the monitoring period of the monitoring thread cannot be affected by cooperative program scheduling, the temporary thread created through the monitoring thread executes overtime processing aiming at the overtime task, the monitoring thread is prevented from directly executing overtime processing to affect the monitoring period, and the temporary thread is automatically destroyed after the execution is finished so as to save resources. By the method and the device, the task operation duration in the coroutine is continuously and stably monitored, and timeout processing is timely executed for the timeout task, so that normal operation of the coroutine is ensured.
Drawings
FIG. 1 is a flow chart of a cooperative monitoring method according to an embodiment of the present application;
FIG. 2 is a timing diagram of a monitoring thread and a coroutine according to an embodiment of the present application;
FIG. 3 is a schematic diagram of a workflow of a coroutine in an embodiment of the present application;
FIG. 4 is a schematic diagram of a workflow of a monitoring thread according to an embodiment of the present application;
fig. 5 is a schematic hardware structure of a coroutine monitoring device according to an embodiment of the present application.
Detailed Description
In order to make the present application solution better understood by those skilled in the art, the following description will clearly and completely describe the technical solution in the embodiments of the present application with reference to the accompanying drawings in the embodiments of the present application, and it is apparent that the described embodiments are only some embodiments of the present application, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.
For the purpose of making the objects, technical solutions and advantages of the present application more apparent, the embodiments of the present application will be described in further detail below with reference to the accompanying drawings.
In a first aspect, an embodiment of the present application provides a coroutine monitoring method.
Fig. 1 is a flow chart illustrating a coroutine monitoring method according to an embodiment of the present application.
Referring to fig. 1, in one embodiment, the coroutine monitoring method includes the following steps:
s11, monitoring the running time of the current task of each cooperative program through a monitoring thread;
s12, if the running time of the current task of a certain cooperative program is longer than the preset task time, creating a temporary thread through a monitoring thread, wherein the temporary thread is used for executing timeout processing on the task and automatically destroying the task after the execution is finished.
Specifically, the monitoring thread and the monitored coroutines are in the same process, the monitoring thread periodically calculates the running time of the current task of each coroutine according to the monitoring period, compares the running time with the preset task time to judge whether a timeout task exists, creates a temporary thread for executing timeout processing on the timeout task if the timeout task exists, and sleeps to the next monitoring period if the timeout task does not exist.
In this embodiment, the monitoring thread monitors the running duration of the current task of each co-program, and compared with the monitoring implemented in the co-program, the monitoring period of the monitoring thread is not affected by the co-program scheduling, and the temporary thread created by the monitoring thread executes the overtime processing for the overtime task, so that the monitoring thread is prevented from directly executing the overtime processing to affect the monitoring period, and the temporary thread is automatically destroyed after the execution is completed so as to save resources. Through the embodiment, the task operation time length in the coroutine is continuously and stably monitored, and the overtime processing is timely executed aiming at the overtime task, so that the coroutine is ensured to normally operate.
Further, in an embodiment, each co-program writes the running start time of the corresponding task into the monitoring thread when each task is scheduled;
for each coroutine, the monitoring thread determines the running time of the current task of the corresponding coroutine according to the current time and the latest written running starting time.
In this embodiment, the co-program scheduling task specifically refers to that a scheduler in a co-program obtains a task to be executed from a task queue, and the running start time of a new monitor thread written in the same co-program Cheng Zui is the running start time of a current task of the co-program, so that the time difference between the current time and the running start time is the running duration of the current task of the co-program.
Optionally, the running start time of the same co-program newly written monitoring thread can overlap the previous running start time, so that the resource occupation is reduced.
Optionally, the preset task duration may be preset in the monitoring thread, and modified according to the actual requirement. The preset task duration can also be recorded in each task of the cooperative program, and the cooperative program also writes the preset task duration of the corresponding task into the monitoring thread when each task is scheduled.
FIG. 2 illustrates a timing diagram for monitoring threads and co-threads in an embodiment of the present application.
Referring to fig. 2, in one embodiment, after the step of creating the temporary thread by the monitoring thread, the method further includes:
monitoring the operation time of the temporary thread through a monitoring thread;
if the operation duration of the temporary thread is longer than the preset thread duration, destroying the temporary thread through the monitoring thread.
In this embodiment, the monitoring thread also monitors the operation duration of the temporary thread after creating the temporary thread, and if the operation duration of the temporary thread is greater than the preset thread duration, it indicates that the timeout processing is not completed due to the exception of the temporary thread, or the temporary thread is not successfully and automatically destroyed after completing the timeout processing. The monitoring thread destroys the temporary thread with overlong operation time, so that the temporary thread is prevented from continuously occupying resources, and when the monitoring thread monitors the overtime task next time and does not have the temporary thread aiming at the overtime task, a new temporary thread is created again, so that normal execution of overtime processing is ensured.
Optionally, the monitoring thread records the creation time as the running start time when creating the temporary thread, and for the temporary thread with the creation time recorded, periodically monitors whether the temporary thread exists, if so, determines the running time of the temporary thread according to the current time and the creation time so as to determine whether the running time of the temporary thread is too long, and if not, deletes the creation time.
In the embodiment shown in fig. 2, the first and second monitoring results of the monitoring thread are that no timeout is detected, and no additional operation is performed. The third monitoring result is that the time-out of the task 2 is monitored, and a temporary thread 1 is created to perform time-out processing on the task 2. The fourth monitoring result is that the time-out of the task 2 is monitored, but the time-out of the temporary thread 1 is not monitored, and no additional operation is executed. The fifth monitoring result is that the task 2 is monitored to be overtime, and the temporary thread 1 is monitored to be overtime, the temporary thread 1 is destroyed, and the temporary thread 2 is created to perform overtime processing on the task 2 again.
Specifically, the monitoring thread in fig. 2 is consistent with the monitoring period of the coroutine task and the temporary thread, so that the operations of destroying the temporary thread 1 and creating the temporary thread 2 are performed in the same monitoring period, and the action sequence can be exchanged. In other embodiments, the monitoring thread may not be consistent with respect to the monitoring period of the coroutine task and the temporary thread. That is, temporary thread 1 is destroyed during the monitoring period of the temporary thread, and temporary thread 2 is created during the monitoring period of the next cooperative task.
Further, in an embodiment, if the running duration of the current task of a certain coroutine is greater than the preset task duration, the step of creating the temporary thread by the monitoring thread includes:
if the running time of the current task of a certain coroutine is longer than the first task time, a first temporary thread is created through the monitoring thread, wherein the first temporary thread is used for marking the coroutine as an unavailable state.
In the cluster, each coroutine has its own state machine, the coroutine in up state (available state) can bear the business, and the coroutine in down state (unavailable state) can not bear the business. In this embodiment, the running duration of the current task of a certain coroutine is longer than the duration of the first task, which indicates that the task has serious overtime and has affected cluster scheduling, and the coroutine is marked as an unavailable state, so as to play an isolating role, prevent fault diffusion and improve the reliability of the system.
Further, in an embodiment, if the running duration of the current task of a certain coroutine is greater than the preset task duration, the step of creating the temporary thread by the monitoring thread further includes:
if the running time of the current task of a certain cooperative program is longer than the second task time, a second temporary thread is created through the monitoring thread, wherein the second task time is shorter than the first task time, the second temporary thread is used for writing the running starting time, the task number, the running time and the call stack of the task and the dispatcher information of the cooperative program into a log, and outputting an alarm prompt.
In this embodiment, the running duration of the current task of a certain cooperative distance is longer than the duration of the second task, which indicates that the task is seriously overtime, and the relevant information of the task and the cooperative distance is written into the log to assist in positioning the problem, so that the alarm prompt is used for reminding the user to perform the problem investigation as soon as possible.
Optionally, the scheduler information includes a thread number to which the scheduler belongs, a scheduler number, a scheduler type, a process to which the scheduler belongs, a task list number, and the like.
FIG. 3 illustrates a workflow diagram of coroutines in an embodiment of the present application.
Referring to fig. 2 and 3, in one embodiment, each co-program writes scheduler information to the supervisory thread in an initialization phase, and writes a running start time and a task number of a corresponding task to the supervisory thread when each task is scheduled.
In this embodiment, regarding that the cooperative procedure may not respond after the task is overtime, the relevant information required for problem positioning cannot be obtained temporarily, so that part of the information required for problem positioning, namely, the scheduler information, the running start time of the corresponding task and the task number, is obtained in advance, the information is unchanged in the task execution process, the call stack of the task is used for characterizing the execution progress of the task, and the information is changed in the task execution process and cannot be obtained in advance, but can be obtained from a third party library (for example, a unbind pstack) according to the thread number to which the scheduler in the scheduler information belongs.
Further, in an embodiment, if the running duration of the current task of a certain coroutine is greater than the preset task duration, the step of creating the temporary thread by the monitoring thread further includes:
if the running time of the current task of a certain cooperative distance is longer than the third task time, creating a third temporary thread through the monitoring thread, wherein the third task time is shorter than the second task time, and the third temporary thread is used for writing the third task time, the running starting time of the task, the task number and the running time into a log.
In this embodiment, the running duration of the current task of a certain coroutine is longer than the duration of the first task, which indicates that the task is not too serious in time-out, and the basic information of the task is written into the log to be used for assisting in positioning the problem.
FIG. 4 illustrates a workflow diagram of a supervisory thread in an embodiment of the present application. In FIG. 4, T 0 For the running time of the current task of a certain coroutine, T 1 For the first task duration, T 2 For the second task duration, T 3 Is the third task duration.
Referring to FIG. 4, in one embodiment, the data is based on T during a single monitoring period 0 The scope in which is located creates a kind of temporary thread, i.e. T 0 ＞T 1 When creating the first temporary thread, T 2 ＜T 0 ≤T 1 When creating the second temporary thread, T 3 ＜T 0 ≤T 2 When in use, the wound is createdAnd establishing a third temporary thread. Under normal conditions, if the final running time length of a task is longer than the first running time length, the monitoring thread can sequentially create a third temporary thread, a second temporary thread and a first temporary thread, and the three threads can be automatically destroyed after the three threads finish timeout processing. In the case that the running time of the individual temporary thread is too long, for example, the running time of the second temporary thread is too long, the monitoring thread monitors T again in the case of destroying the second temporary thread 0 ＞T 1 The second temporary thread is not repeatedly created but the first temporary thread is created directly. And when the running time of the first temporary thread is too long, the monitoring thread destroys and recreates the first temporary thread until the corresponding coroutine is marked as an unavailable state.
In a second aspect, an embodiment of the present application further provides a cooperative distance monitoring apparatus. In one embodiment, the cooperative distance monitoring device includes:
the monitoring module is used for monitoring the running time of the current task of each protocol through the monitoring thread;
the creating module is used for creating a temporary thread through the monitoring thread if the running time of the current task of a certain cooperative program is longer than the preset task time, wherein the temporary thread is used for executing timeout processing on the task and is automatically destroyed after the execution is finished.
Further, in an embodiment, the monitoring module is further configured to monitor, by the monitoring thread, a running duration of the temporary thread;
the coroutine monitoring device also comprises a destroying module, which is used for destroying the temporary thread through the monitoring thread if the operation duration of the temporary thread is longer than the preset thread duration.
Further, in an embodiment, the creating module is configured to:
if the running time of the current task of a certain coroutine is longer than the first task time, a first temporary thread is created through the monitoring thread, wherein the first temporary thread is used for marking the coroutine as an unavailable state.
Further, in an embodiment, the creating module is further configured to:
if the running time of the current task of a certain cooperative program is longer than the second task time, a second temporary thread is created through the monitoring thread, wherein the second task time is shorter than the first task time, the second temporary thread is used for writing the running starting time, the task number, the running time and the call stack of the task and the dispatcher information of the cooperative program into a log, and outputting an alarm prompt.
Further, in an embodiment, the creating module is further configured to:
if the running time of the current task of a certain cooperative distance is longer than the third task time, creating a third temporary thread through the monitoring thread, wherein the third task time is shorter than the second task time, and the third temporary thread is used for writing the third task time, the running starting time of the task, the task number and the running time into a log.
Further, in an embodiment, each co-program writes scheduler information into the monitoring thread in an initialization phase, and writes a running start time and a task number of a corresponding task into the monitoring thread when each task is scheduled.
Further, in an embodiment, each co-program writes the running start time of the corresponding task into the monitoring thread when each task is scheduled;
for each coroutine, the monitoring thread determines the running time of the current task of the corresponding coroutine according to the current time and the latest written running starting time.
The function implementation of each module in the cooperative distance monitoring device corresponds to each step in the cooperative distance monitoring method embodiment, and the function and implementation process of each module are not described here in detail.
In a third aspect, an embodiment of the present application provides a coroutine monitoring device, where the coroutine monitoring device may be a device with a data processing function, such as a personal computer (personal computer, PC), a notebook computer, a server, or the like.
Fig. 5 shows a schematic hardware structure of the coroutine monitoring device according to the embodiment of the present application.
Referring to fig. 5, in an embodiment of the present application, a coroutine monitoring device may include a processor, a memory, a communication interface, and a communication bus.
The communication bus may be of any type for implementing the processor, memory, and communication interface interconnections.
The communication interfaces include input/output (I/O) interfaces, physical interfaces, logical interfaces, and the like for implementing device interconnections within the coroutine monitoring device, and interfaces for implementing interconnection of the coroutine monitoring device with other devices (e.g., other computing devices or user devices). The physical interface may be an ethernet interface, a fiber optic interface, an ATM interface, etc.; the user device may be a Display, a Keyboard (Keyboard), or the like.
The memory may be various types of storage media such as random access memory (random access memory, RAM), read-only memory (ROM), nonvolatile RAM (non-volatile RAM, NVRAM), flash memory, optical memory, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (electrically erasable PROM, EEPROM), and the like.
The processor may be a general-purpose processor, and the general-purpose processor may call a coroutine monitoring program stored in the memory and execute the coroutine monitoring method provided in the embodiment of the present application. For example, the general purpose processor may be a central processing unit (central processing unit, CPU). The method executed when the cooperative journey monitoring program is called may refer to various embodiments of the cooperative journey monitoring method of the present application, and will not be described herein.
Those skilled in the art will appreciate that the hardware configuration shown in fig. 5 is not limiting of the application and may include more or fewer components than shown, or may combine certain components, or a different arrangement of components.
In a fourth aspect, embodiments of the present application also provide a readable storage medium.
The program is stored on a readable storage medium, wherein when the program is executed by a processor, the method realizes the steps of the program.
The method implemented when the cooperative journey monitoring program is executed may refer to various embodiments of the cooperative journey monitoring method of the present application, which are not described herein.
It should be noted that, the foregoing embodiment numbers are merely for describing the embodiments, and do not represent the advantages and disadvantages of the embodiments.
The terms "comprising" and "having" and any variations thereof in the description and claims of the present application and in the foregoing drawings are intended to cover non-exclusive inclusions. For example, a process, method, system, article, or apparatus that comprises a list of steps or elements is not limited to only those listed steps or elements but may include other steps or elements not listed or inherent to such process, method, article, or apparatus. The terms "first," "second," and "third," etc. are used for distinguishing between different objects and not necessarily for describing a sequential or chronological order, and are not limited to the fact that "first," "second," and "third" are not identical.
In the description of embodiments of the present application, "exemplary," "such as," or "for example," etc., are used to indicate an example, instance, or illustration. Any embodiment or design described herein as "exemplary," "such as" or "for example" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. Rather, the use of words such as "exemplary," "such as" or "for example," etc., is intended to present related concepts in a concrete fashion.
In the description of the embodiments of the present application, unless otherwise indicated, "/" means or, for example, a/B may represent a or B; the text "and/or" is merely an association relation describing the associated object, and indicates that three relations may exist, for example, a and/or B may indicate: the three cases where a exists alone, a and B exist together, and B exists alone, and in addition, in the description of the embodiments of the present application, "plural" means two or more than two.
In some of the processes described in the embodiments of the present application, a plurality of operations or steps occurring in a particular order are included, but it should be understood that these operations or steps may be performed out of the order in which they occur in the embodiments of the present application or in parallel, the sequence numbers of the operations merely serve to distinguish between the various operations, and the sequence numbers themselves do not represent any order of execution. In addition, the processes may include more or fewer operations, and the operations or steps may be performed in sequence or in parallel, and the operations or steps may be combined.
From the above description of the embodiments, it will be clear to those skilled in the art that the above-described embodiment method may be implemented by means of software plus a necessary general hardware platform, but of course may also be implemented by means of hardware, but in many cases the former is a preferred embodiment. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art in the form of a software product stored in a storage medium (e.g. ROM/RAM, magnetic disk, optical disk) as described above, comprising several instructions for causing a terminal device to perform the method described in the various embodiments of the present application.
The foregoing description is only of the preferred embodiments of the present application, and is not intended to limit the scope of the claims, and all equivalent structures or equivalent processes using the descriptions and drawings of the present application, or direct or indirect application in other related technical fields are included in the scope of the claims of the present application.
Claims (10)
1. The cooperative distance monitoring method is characterized by comprising the following steps of:
monitoring the running time of the current task of each cooperative distance through a monitoring thread;
if the running time of the current task of a certain cooperative program is longer than the preset task time, creating a temporary thread through the monitoring thread, wherein the temporary thread is used for executing timeout processing for the task and automatically destroying the task after the execution is finished.
2. The coroutine monitoring method of claim 1, further comprising, after the step of creating a temporary thread by the monitoring thread:
monitoring the operation time of the temporary thread through a monitoring thread;
if the operation duration of the temporary thread is longer than the preset thread duration, destroying the temporary thread through the monitoring thread.
3. The coroutine monitoring method according to claim 1, wherein if the running duration of the current task of a coroutine is longer than the preset task duration, the step of creating the temporary thread by the monitoring thread includes:
if the running time of the current task of a certain coroutine is longer than the first task time, a first temporary thread is created through the monitoring thread, wherein the first temporary thread is used for marking the coroutine as an unavailable state.
4. The coroutine monitoring method according to claim 3, wherein if the running duration of the current task of a coroutine is longer than the preset task duration, the step of creating the temporary thread by the monitoring thread further comprises:
if the running time of the current task of a certain cooperative program is longer than the second task time, a second temporary thread is created through the monitoring thread, wherein the second task time is shorter than the first task time, the second temporary thread is used for writing the running starting time, the task number, the running time and the call stack of the task and the dispatcher information of the cooperative program into a log, and outputting an alarm prompt.
5. The coroutine monitoring method according to claim 4, wherein if the running duration of the current task of a coroutine is longer than the preset task duration, the step of creating the temporary thread by the monitoring thread further comprises:
if the running time of the current task of a certain cooperative distance is longer than the third task time, creating a third temporary thread through the monitoring thread, wherein the third task time is shorter than the second task time, and the third temporary thread is used for writing the third task time, the running starting time of the task, the task number and the running time into a log.
6. The coroutine monitoring method according to claim 4, wherein each coroutine writes scheduler information into the monitoring thread in an initialization stage, and writes a running start time and a task number of a corresponding task into the monitoring thread when each task is scheduled.
7. The coroutine monitoring method according to any one of claims 1 to 6, wherein each coroutine writes a running start time of a corresponding task into the monitoring thread when scheduling each task;
for each coroutine, the monitoring thread determines the running time of the current task of the corresponding coroutine according to the current time and the latest written running starting time.
8. A coroutine monitoring device, characterized in that the coroutine monitoring device comprises:
the monitoring module is used for monitoring the running time of the current task of each protocol through the monitoring thread;
the creating module is used for creating a temporary thread through the monitoring thread if the running time of the current task of a certain cooperative program is longer than the preset task time, wherein the temporary thread is used for executing timeout processing on the task and is automatically destroyed after the execution is finished.
9. Co-program monitoring device, characterized in that it comprises a processor, a memory, and a co-program monitoring program stored on the memory and executable by the processor, wherein the co-program monitoring program, when executed by the processor, implements the steps of the co-program monitoring method according to any of claims 1 to 7.
10. A readable storage medium, wherein a co-program monitor is stored on the readable storage medium, wherein the co-program monitor, when executed by a processor, implements the steps of the co-program monitor method according to any one of claims 1 to 7.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311693341.7A CN117519947A (en) | 2023-12-08 | 2023-12-08 | Coroutine monitoring method, device, equipment and readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202311693341.7A CN117519947A (en) | 2023-12-08 | 2023-12-08 | Coroutine monitoring method, device, equipment and readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN117519947A true CN117519947A (en) | 2024-02-06 |
Family
ID=89747765
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202311693341.7A Pending CN117519947A (en) | 2023-12-08 | 2023-12-08 | Coroutine monitoring method, device, equipment and readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN117519947A (en) |
-
2023
- 2023-12-08 CN CN202311693341.7A patent/CN117519947A/en active Pending
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6499986B2 (en) | Fault tolerant batch processing | |
| US7406699B2 (en) | Enhanced runtime hosting | |
| US20090260011A1 (en) | Command line transactions | |
| CN110427252B (en) | Task scheduling method, device and storage medium based on task dependency relationship | |
| CN110704173A (en) | Task scheduling method, scheduling system, electronic device and computer storage medium | |
| CN111400011B (en) | Real-time task scheduling method, system, equipment and readable storage medium | |
| CN109298951A (en) | The execution method and terminal device of Celery task | |
| US20100257544A1 (en) | Method of establishing a logical state of an instance using non-deterministic operation results stored in a result log | |
| CN110162344B (en) | Isolation current limiting method and device, computer equipment and readable storage medium | |
| CN110611707A (en) | Task scheduling method and device | |
| CN107861715B (en) | Service establishing system and method | |
| CN110990132B (en) | Asynchronous task processing method and device, computer equipment and storage medium | |
| CN112181619A (en) | Scheduling method, device, equipment and medium for batch service | |
| CN111666141A (en) | Task scheduling method, device and equipment and computer storage medium | |
| CN113485812B (en) | Partition parallel processing method and system based on large-data-volume task | |
| CN110908644B (en) | Configuration method and device of state node, computer equipment and storage medium | |
| US20080313652A1 (en) | Notifying user mode scheduler of blocking events | |
| CN117519947A (en) | Coroutine monitoring method, device, equipment and readable storage medium | |
| CN108521524B (en) | Agent collaborative task management method and device, computer equipment and storage medium | |
| CN107958414B (en) | Method and system for eliminating long transactions of CICS (common integrated circuit chip) system | |
| CN109040491B (en) | Hanging-up behavior processing method and device, computer equipment and storage medium | |
| CN113806055A (en) | Lightweight task scheduling method, system, device and storage medium | |
| CN111767125B (en) | Task execution method, device, electronic equipment and storage medium | |
| CN112948096A (en) | Batch scheduling method, device and equipment | |
| CN113052571A (en) | Method and device for processing workflow critical path |
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 |