Coroutine resuming method based on line number state, electronic device, and storage medium

Abstract

The application belongs to the technical field of embedded software, and particularly relates to a coroutine recovery method based on a line number state, an electronic device and a storage medium. The method comprises the following steps: in response to a task entry function of a target task being called, reading a coroutine state record of the target task; when a recovery state value is an initial value, executing the target task from an initial position; when the recovery state value is a non-initial value, entering an execution branch corresponding to a source code line number according to the recovery state value; when the target task executes to a coroutine pause statement, writing the source code line number into the recovery state value, writing at least one of a waiting deadline and a synchronization trigger condition into waiting condition information, and exiting the task entry function; when the waiting deadline arrives or the synchronization trigger condition is satisfied, calling the task entry function again and continuing to execute the target task. The application can reduce the dependence of task recovery on a complete thread stack, and improve the consistency of the coroutine pause, waiting and recovery processes.

Description

Technical Field

[0001] This invention relates to the field of embedded software technology, specifically to a method for coroutine recovery based on row number status, an electronic device, and a storage medium. Background Technology

[0002] In embedded software and lightweight task management systems, coroutine resumption mechanisms allow tasks to temporarily exit execution during waiting times, external synchronization conditions, or resource conditions, and resume execution once the conditions are met. Compared to traditional blocking tasks, coroutine execution reduces processor idling and resource consumption during task waiting periods, which is of great significance for small microcontrollers, real-time control programs, and multi-tasking firmware.

[0003] Existing solutions employ two main approaches: one relies on the real-time operating system to maintain an independent task stack for each task, restoring task states through context switching. However, this increases memory consumption and can limit the number of tasks in resource-constrained environments. Another approach uses a standard state machine or callback functions to break down the task flow, but this typically requires developers to manually define state numbers, maintain state transition relationships, and synchronously modify the state table as the task flow changes, resulting in poor code readability and maintainability. For tasks involving delayed waiting, synchronous waiting, and timeout returns, if the recovery location, waiting conditions, and recovery reasons are not managed uniformly, problems such as duplicate task execution, lost waiting states, unclear timeout judgments, or incorrect recovery paths are likely to occur. Therefore, a coroutine recovery handling method is needed that does not rely on a complete thread stack but can explicitly record the recovery location and waiting conditions. Summary of the Invention

[0004] This invention provides a coroutine recovery method, electronic device, and storage medium based on line number status, which at least solves the problem of how to resume a task from its original execution position after it has been paused without relying on the complete thread stack.

[0005] In a first aspect, the present invention provides a coroutine recovery method based on row number status, the method comprising: In response to the task entry function of the target task being called, the coroutine status record of the target task is read. The coroutine status record includes the recovery status value and waiting condition information. The recovery status value records the source code line number when the target task exits. When the restored state value is the initial value, the target task is executed from the initial position; When the recovery status value is not the initial value, the execution branch corresponding to the source code line number is entered according to the recovery status value; When the target task reaches the coroutine pause statement, write the source code line number corresponding to the coroutine pause statement into the recovery status value, write at least one of the waiting deadline and synchronization trigger conditions into the waiting condition information, and exit the task entry function. In response to the arrival of the waiting deadline or the fulfillment of the synchronization trigger condition, the task entry function is called, the execution branch is restored according to the recovery status value, and the target task continues to be executed according to the waiting condition information.

[0006] In one possible implementation, the source code line number is the actual line number in the source file where the target task is located, and the task entry function has an execution branch corresponding to the source code line number.

[0007] In one possible implementation, entering the execution branch corresponding to the source code line number includes: using the recovery state value as the branch selection value of the switch statement; and entering the case branch when the branch selection value matches the source code line number corresponding to the case branch, so as to continue executing the target task from the position corresponding to the source code line number.

[0008] In one possible implementation, the coroutine pause statement includes a delayed wait statement and a synchronous wait statement; the delayed wait statement is used to instruct the target task to wait until the waiting deadline is reached; the synchronous wait statement is used to instruct the target task to wait for the synchronous triggering condition to be met and to set the waiting deadline.

[0009] In one possible implementation, at least one of the waiting deadline and the synchronization triggering condition is written into the waiting condition information, including: when the target task executes to the delayed waiting statement, the waiting deadline is written into the waiting condition information; when the target task executes to the synchronization waiting statement, the synchronization triggering condition and the waiting deadline are written into the waiting condition information.

[0010] In one possible implementation, after exiting the task entry function, the method further includes: if the waiting condition information includes a waiting deadline, storing the target task and the waiting deadline in a scheduling list; if the waiting condition information includes a synchronization trigger condition, marking the target task as a waiting state, the waiting state indicating that the target task is waiting for the synchronization trigger condition to be met; and in response to the arrival of the waiting deadline in the scheduling list, or the synchronization trigger condition corresponding to the waiting state being met, calling the task entry function again.

[0011] In one possible implementation, continuing to execute the target task based on the waiting condition information includes: if the waiting condition information includes a synchronization trigger condition and a waiting deadline, and the synchronization trigger condition is detected to be met when the current time is earlier than the waiting deadline, determining the waiting return result as a normal wake-up; if the waiting condition information includes a synchronization trigger condition and a waiting deadline, and the synchronization trigger condition is not detected to be met when the current time reaches or exceeds the waiting deadline, determining the waiting return result as a waiting timeout; and continuing to execute the target task based on the waiting return result.

[0012] In one possible implementation, the method further includes: resetting the recovery state value to the initial value and clearing the waiting condition information when the target task finishes execution.

[0013] In a second aspect, the present invention provides an electronic device comprising a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement a coroutine recovery method based on line number state.

[0014] Thirdly, the present invention provides a computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to implement a coroutine recovery method based on line number state.

[0015] Compared with the prior art, the advantages and beneficial effects of the present invention are as follows: By reading the coroutine status record when the task entry function of the target task is called, the unified acquisition of the task recovery position and waiting conditions is realized, so that when the task is executed again, it can directly enter the subsequent processing flow based on the existing status.

[0016] By setting the recovery status value to the source code line number when the target task exits, the correspondence between the recovery location and the actual pause location in the program source file is achieved, reducing the risk of mismatch caused by manual maintenance of status numbers.

[0017] By executing the target task from the initial position when the restored state value is the initial value, and entering the execution branch corresponding to the source code line number when the restored state value is not the initial value, the flow control between initial execution and restored execution is achieved.

[0018] By writing the source code line number, waiting deadline, or synchronization trigger condition when the target task executes to the coroutine pause statement, the task pause position, time waiting condition, and synchronization waiting condition are synchronously saved.

[0019] By calling the task entry function again when the deadline is reached or the synchronization trigger condition is met, a closed loop is achieved to return the task from the paused state to the executable state.

[0020] By restoring to the execution branch based on the recovery state value and continuing to execute the target task based on the waiting condition information, coroutine recovery without saving the complete thread stack is achieved, reducing the overhead of task state saving in resource-constrained environments and improving the consistency of task waiting, recovery and timeout handling. Attached Figure Description

[0021] Figure 1 This is a schematic flowchart of the method of the present invention; Figure 2 This is the line number status recovery process of the present invention; Figure 3 This invention provides a process for writing coroutine pause and wait conditions; Figure 4 This is a process for re-invoking and waiting for the result judgment in this invention. Detailed Implementation

[0022] Hereinafter, embodiments of the present invention will be described with reference to the accompanying drawings. However, it should be understood that these descriptions are exemplary only and are not intended to limit the scope of the invention. In the following detailed description, numerous specific details are set forth to provide a thorough understanding of the embodiments of the invention for ease of explanation. However, it will be apparent that one or more embodiments may be practiced without these specific details. Furthermore, descriptions of well-known structures and techniques are omitted in the following description to avoid unnecessarily obscuring the concept of the invention.

[0023] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. The terms “comprising,” “including,” etc., as used herein indicate the presence of relevant features, steps, operations, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, or components.

[0024] All terms used herein (including technical and scientific terms) have the meanings commonly understood by those skilled in the art, unless otherwise defined. It should be noted that the terms used herein are to be interpreted in a manner consistent with the context of this specification, and not in an idealized or overly rigid way.

[0025] Line number status refers to a status expression method that uses the code position of a task in the source file as the basis for task resumption. For tasks written in sequential code, when a task reaches a waiting statement, delayed statement, or synchronous statement during execution, its current position can usually be uniquely identified by a specific line number in the source file. After writing this line number into the task's corresponding status record, the line number no longer merely represents a text position in the source code, but serves as a status value for resuming execution when the task is next invoked, indicating which execution branch the task should enter and from which waiting position to continue running. Compared to manually defining status numbers, line number status allows the resumption status to directly correspond to the actual code position, reducing maintenance deviations between status numbers and code structure. Based on this idea, this invention uses the source code line number when the target task exits as the resumption status value, and combines it with waiting condition information such as waiting deadline and synchronization trigger conditions to achieve the location, resumption, and continuation of execution of the target task when it is invoked again after being paused and exited.

[0026] like Figure 1 As shown, a coroutine recovery method based on row number status is described, the method comprising: In response to the task entry function of the target task being called, the coroutine status record of the target task is read. The coroutine status record includes the recovery status value and waiting condition information. The recovery status value records the source code line number when the target task exits. The target task is carried by the task entry function in the embedded program. When the task entry function is called by the scheduler, the processor enters the program segment corresponding to the task entry function and reads the coroutine status record from the task context. The coroutine status record includes at least a recovery status value and waiting condition information. The recovery status value is used to store the source code line number recorded when the target task last exited, and the waiting condition information is used to store the waiting deadline or synchronization trigger condition associated with the target task's exit. After reading the coroutine status record, the task entry function checks the validity of the recovery status value. When the recovery status value is null, zero, or a system-defined initial identifier, the target task executes according to the initial position of the task entry function; when the recovery status value is not an initial value, the task entry function uses the recovery status value as the basis for the recovery position and enters the execution branch matching the source code line number. This process ensures that when the target task is called again, it does not rely on the complete thread stack recovery, but instead enters the program branch corresponding to the last exit position based on the saved line number status, and retains the read waiting condition information for subsequent waiting result judgment.

[0027] The source code line number is the actual line number in the source file where the target task is located, and the task entry function has an execution branch corresponding to the source code line number.

[0028] In one embodiment, the source code line number uses the actual line number in the source file where the target task is located. This constraint directly binds the recovery status value to the program position in the source file, avoiding the problem of inconsistency between the status number and program statement when the status stage is maintained by manual numbering. The task code of the target task is instantiated in units of a task entry function in a single source file. The task entry function has an execution branch corresponding to the actual line number. The execution branch can be implemented using the switch statement and case branch in C language. The recovery status value is used as the branch selection value of the switch statement, and the branch identifier of the case branch uses the actual line number of the coroutine pause statement. When the task entry function is called, the program reads the recovery status value and enters the switch statement; when the recovery status value matches the actual line number of a certain case branch, the program enters that case branch and continues to execute the target task from the subsequent statements of that case branch. When the recovery status value is the initial value, the program does not enter the line number recovery branch, and the task entry function is executed in the usual order of initialization segment, task entry segment, and task loop segment.

[0029] To ensure stable identification of actual line numbers, the task source file maintains the line number correspondence between the task entry function and the coroutine pause statement during the compilation phase. The coroutine pause statement can encapsulate the line number recording action using macro statements. When the macro expands, it reads the current source code line number, writes it into the recovery status value in the coroutine status record, and generates the corresponding case branch at the same location. This way, when developers insert delayed or synchronous wait statements into the task body, they do not need to manually maintain the status numbers; the task entry function can locate the recovery position based on the source code line number. If multiple target tasks exist within the same source file, each target task holds an independent coroutine status record, and the recovery status value only participates in branch selection within the corresponding target task's task entry function. If the project requires multiple tasks to be implemented in different source files, each task entry function still uses the actual line number in its own source file as the source of the recovery status value, and the recovery action is only performed within the current task entry function, without using line numbers from other source files across task entry functions.

[0030] In this implementation, the execution branch is not a manual enumeration of ordinary business states, but a recovery entry point formed by source code line numbers. The source code line number is determined based on the actual line number of the source file where the coroutine pause statement is located, and the branch identifier in the task entry function is consistent with this actual line number. If the source file is modified by adding or deleting lines before compilation, the recovery state value and the branch identifier are updated synchronously in the program generated in the same compilation. The running program does not modify the source file during runtime, so the recovery position will not change due to changes in the source file text during runtime. If the recovery state value has already been written before the target task exits, when the task entry function is called again, only the recovery state value and waiting condition information need to be read, and it is not necessary to save the complete call stack where ordinary local variables are located. For intermediate business data that needs to be used after pause, it can be saved by the task itself to the task context, static variables, or business buffer. The coroutine state record is only responsible for saving the recovery position and waiting conditions and does not assume the responsibility of business data persistence. This keeps the line number recovery mechanism and task business data management clearly separated, making it easy to implement in a small-resource microcontroller environment.

[0031] When the restored state value is the initial value, the target task is executed from the initial position; When the recovery status value is not the initial value, the execution branch corresponding to the source code line number is entered according to the recovery status value; like Figure 2As shown, after reading the coroutine status record, the task entry function judges the recovery status value. If the recovery status value is the initial value, it means the target task did not record a valid pause position in the previous execution. The processor executes the target task from the pre-set initial position in the task entry function and completes necessary initialization, enters the task loop, or performs business processing. If the recovery status value is not the initial value, it means the target task recorded the source code line number before the previous exit. The task entry function does not re-execute the target task according to the initial path, but uses the recovery status value as the recovery position and enters the execution branch corresponding to the source code line number. The statements within the execution branch maintain a correspondence with the location of the coroutine pause statement. The target task continues running from this execution branch, and, based on the read waiting condition information, determines whether this recovery is time-based or synchronization-based. This stage completes the closed loop from status reading to program recovery entry point location, enabling the target task to return to the previous pause position when called again.

[0032] Entering the execution branch corresponding to the source code line number includes: using the recovery status value as the branch selection value of the switch statement; and entering the case branch when the branch selection value matches the source code line number corresponding to the case branch, so as to continue executing the target task from the position corresponding to the source code line number.

[0033] In one embodiment, when entering the execution branch corresponding to the source code line number, a new constraint is added: the recovery status value is used as the branch selection value of the switch statement, and the recovery position matching is achieved using the source code line number corresponding to the case branch. The task entry function internally sets up a status selection structure, which receives the recovery status value as input. When the recovery status value is the initial value, the status selection structure does not enter any line number recovery branch, and the program runs according to the initial execution path in the task entry function. When the recovery status value is not the initial value, the status selection structure matches the recovery status value with each case branch identifier one by one. The case branch identifier uses the source code line number where the coroutine pause statement is located. When the branch selection value matches the source code line number corresponding to a certain case branch, the program enters that case branch and continues execution of the target task from the position corresponding to that source code line number.

[0034] In this implementation, the `switch` statement provides a re-enterable state selection entry point, and the `case` branch carries the position for continuing execution after resumption. When the coroutine pause statement is triggered during the previous execution of the target task, the current source code line number is written to the recovery state value. When the task entry function is called again, the recovery state value is not interpreted as a normal business state, but rather used as a program position identifier for branch matching. If the match is successful, the program skips the statements in the task entry function that are before the given source code line number, have been completed, and do not need to be repeated, and directly enters the subsequent statements corresponding to the pause position. This avoids the target task from repeating execution from the beginning due to waiting, delay, or synchronization blocking, and also eliminates the need to save the complete thread stack for the task.

[0035] In practical engineering implementation, coroutine pause statements can be encapsulated by macro statements, including line number writing, wait condition writing, and function exit actions. When a macro statement expands, it forms a case branch at the current position, using the current source code line number as its identifier. When developers place delayed wait statements, semaphore wait statements, queue wait statements, or event wait statements in the task body, the program can automatically generate a recovery branch corresponding to that wait position. If multiple coroutine pause statements exist, each with a different source code line number, and each line number corresponds to a different case branch. The recovery state value only saves the source code line number before the target task's most recent exit; therefore, when the task entry function is called again, it will only enter a matching branch.

[0036] When the restored state value is not the initial value but no case branch is matched, this situation can be considered a state record exception. In actual implementation, the restored state value can be reset to the initial value and the waiting condition information can be cleared, allowing the target task to re-enter according to the initial path; alternatively, the target task can be stopped and an internal error flag can be output. The specific handling method used depends on the system's requirements for task continuity and error isolation. For resource-constrained microcontroller environments, resetting the restored state value is usually preferred to avoid invalid line numbers causing the task entry function to repeatedly enter the exception path. This boundary handling does not change the main flow of line number restoration; it only ensures that the coroutine state record can return to a re-executable state when branch matching fails.

[0037] When the target task reaches the coroutine pause statement, write the source code line number corresponding to the coroutine pause statement into the recovery status value, write at least one of the waiting deadline and synchronization trigger conditions into the waiting condition information, and exit the task entry function. like Figure 3As shown, when the target task reaches the coroutine pause statement in the task entry function, the processor executes the state-saving logic encapsulated in the coroutine pause statement. The coroutine pause statement reads the current source code line number, writes this line number into the recovery state value in the coroutine state record, and generates waiting condition information based on the type of the coroutine pause statement. The waiting condition information can include a waiting deadline, a synchronization trigger condition, or both. After writing, the target task no longer occupies the current execution flow, and the task entry function returns directly to the caller. The scheduler or task management program determines whether the target task enters a time-based wait, a synchronization condition wait, or a synchronous wait with timeout constraints based on the waiting condition information, so that the target task can return to the position corresponding to the coroutine pause statement and continue running when it is called again.

[0038] like Figure 3 As shown, coroutine pause statements include delayed wait statements and synchronous wait statements; delayed wait statements are used to instruct the target task to wait until the waiting deadline is reached; synchronous wait statements are used to instruct the target task to wait for the synchronous triggering condition to be met, and set the waiting deadline.

[0039] In one embodiment, the coroutine pause statement is further limited to a delayed wait statement and a synchronous wait statement. This limitation distinguishes between scenarios where the target task actively relinquishes execution rights over time, and scenarios where the target task waits for other tasks, peripheral callbacks, or system events to trigger. The delayed wait statement instructs the target task to wait until a waiting deadline is reached. The waiting deadline is determined by the system time base and delay duration during task execution. The system time base can be a millisecond count, microsecond count, or other monotonically increasing software count value maintained by the scheduler. The delay duration is passed in when the delayed wait statement is called. When the task reaches the delayed wait statement, the delayed wait statement does not execute a business blocking loop. Instead, it writes the calculated waiting deadline into the waiting condition information and causes the task entry function to exit. In this way, the target task will not continuously occupy the processor during the waiting period, and the scheduler will call the task entry function again when the waiting deadline is reached.

[0040] The `synchronization wait` statement is used to instruct a target task to wait for a synchronization trigger condition to be met, and sets a wait deadline. Synchronization trigger conditions can be generated by common synchronization objects such as semaphore release, data reception in a message queue, mutex acquisition, or event flag satisfaction. When the `synchronization wait` statement is executed, the task management program writes the synchronization object identifier, wait type, and synchronization trigger condition into the wait condition information, and uses the wait deadline as a timeout boundary. The wait deadline can be determined based on the longest wait duration passed when the `synchronization wait` statement is called; if the system allows indefinite waiting, a system-defined no-timeout flag can be used, but this no-timeout flag must have a fixed meaning in the task management program and cannot be mixed with ordinary time values.

[0041] Both delayed wait statements and synchronous wait statements share line number records and task exit frameworks, but the content of the wait condition information they write differs. Delayed wait statements only need to wait for the deadline to determine when to call again. Synchronous wait statements, in addition to waiting for the deadline, also require a synchronization trigger condition to determine whether the target task has prematurely recovered due to changes in the synchronization object. For event-driven wait scenarios, event identifiers and event fulfillment rules can be recorded in the synchronization trigger condition. The event fulfillment rule is used to limit recovery to the condition that any one event is met, or recovery is only possible when multiple events are met. The target task enters only the waiting process corresponding to one wait statement at a time, avoiding the situation where the same coroutine state record is bound to multiple unrelated synchronization objects, leading to unclear recovery reasons. If the business requires waiting for multiple events, these events need to be grouped into the same event waiting rule, which will then uniformly determine whether the recovery condition has been met.

[0042] Write at least one of the waiting deadline and the synchronization triggering condition into the waiting condition information, including: writing the waiting deadline into the waiting condition information when the target task executes to the delayed waiting statement; and writing the synchronization triggering condition and the waiting deadline into the waiting condition information when the target task executes to the synchronization waiting statement.

[0043] In one embodiment, the process of writing the waiting condition information is further limited to writing different fields according to the type of the coroutine pause statement. This limitation ensures that subsequent recovery judgments have clear input. When the target task executes to the delayed wait statement, the task management program obtains the waiting duration from the delayed wait statement, generates a waiting deadline based on the current system time base, and writes the waiting deadline into the waiting condition information. A waiting type identifier can be synchronously written into the waiting condition information, indicating that this pause is a time-based wait. The waiting type identifier is not a business status number, but rather an internal field used by the task management program to distinguish the reason for recovery. Before the task entry function exits, the recovery status value has recorded the source code line number where the delayed wait statement is located, and the waiting condition information has recorded the waiting deadline; these two records together constitute the necessary information for delayed wait recovery.

[0044] When the target task executes to the synchronization wait statement, the task management program retrieves the synchronization object, synchronization trigger condition, and maximum wait duration from the statement. The synchronization object is used to locate the object that triggers the wake-up action, such as a semaphore, message queue, mutex, or event flag set. The synchronization trigger condition specifies the state at which the target task can resume execution. The maximum wait duration sets the wait deadline. The task management program writes the synchronization trigger condition and wait deadline into the wait condition information and sets the wait type identifier to synchronous wait. If the maximum wait duration passed to the synchronization wait statement is zero, it indicates that only the synchronization trigger condition is checked without entering actual waiting; if the maximum wait duration passed to the synchronization wait statement is the system-defined no-timeout flag, it indicates that the target task only depends on the synchronization trigger condition to resume.

[0045] Waiting condition information can be stored using a structure. The structure must at least contain a waiting deadline field and a synchronization trigger condition field. In the implementation, a waiting type field, a synchronization object field, and a waiting return result field can also be set. The waiting deadline field can be used in both delayed and synchronous waiting, while the synchronization trigger condition field is only valid in synchronous waiting. The synchronization object field is used to attach the target task to the corresponding synchronization object's waiting list or waiting set. The waiting return result field is written with states such as normal wake-up, waiting timeout, or no waiting result during recovery, allowing the target task to continue executing its business branch at the recovery point. The validity of the fields is constrained by the waiting type field. For example, when the waiting type is delayed waiting, the synchronization trigger condition field is not involved in the judgment; when the waiting type is synchronous waiting, both the waiting deadline and the synchronization trigger condition are involved in the recovery reason judgment.

[0046] To prevent incomplete writing of waiting condition information from causing the target task to fail to recover, the task management program can perform necessary checks before exiting the task entry function. For delayed wait statements, it checks whether the wait deadline has been written; for synchronous wait statements, it checks whether the synchronization trigger condition has been written and whether the wait deadline is a valid time value or has no timeout flag. If the checks fail, the recovery status value can be reset to its initial value and an internal error flag can be returned, or the target task can be prevented from entering the waiting state. This exception handling is only used for project boundary protection and does not change the basic process of coroutine recovery based on source code line numbers. Under normal circumstances, after the coroutine pause statement completes the writing of the necessary content in the source code line number, wait deadline, and synchronization trigger condition, the task entry function exits, and the target task waits for the next scheduling to enter the recovery process.

[0047] After exiting the task entry function, the method further includes: if the waiting condition information includes a waiting deadline, storing the target task and the waiting deadline in the scheduling list; if the waiting condition information includes a synchronization trigger condition, marking the target task as a waiting state, the waiting state being used to indicate that the target task is waiting for the synchronization trigger condition to be met; and calling the task entry function again in response to the arrival of the waiting deadline in the scheduling list, or the synchronization trigger condition corresponding to the waiting state being met.

[0048] In one embodiment, after the task entry function exits, the task management program connects the target task to the subsequent scheduling process based on waiting condition information. This limitation indicates that the target task will not be removed from system management after exiting. When the waiting condition information includes a waiting deadline, the task management program associates the target task with the waiting deadline and stores it in the scheduling list. The scheduling list can be a time-sorted linked list, an array queue, or a min-heap structure, with the specific data structure determined based on the target device resources and the number of tasks. Resource-constrained microcontrollers typically use linked lists or static array queues to avoid dynamic memory allocation. When inserting a target task, the task management program uses the waiting deadline as the sorting criterion, placing target tasks with earlier waiting deadlines in positions that are more easily checked by scheduling. The scheduler periodically checks the scheduling list, or triggers a check when the most recent waiting deadline arrives, to determine the target tasks that need to have their task entry function called again.

[0049] When the waiting condition information includes the synchronization trigger condition, the task manager marks the target task as waiting. The waiting state indicates that the target task is waiting for the synchronization trigger condition to be met, rather than being in an immediately runnable state. When a target task enters the waiting state, it can be added to the waiting list corresponding to the synchronization object, or the synchronization object identifier and synchronization trigger condition can be recorded in the task control table. When other tasks, peripheral interrupt bottom halves, or system callbacks change the state of the synchronization object, the task manager checks whether the synchronization trigger condition is met. When the synchronization trigger condition is met, the target task switches from the waiting state to the callable state, and the task entry function is called again. If a waiting deadline is set for the synchronization wait, the target task can either be added to the waiting list of the synchronization object or stored in the scheduling list associated with the waiting deadline. If the synchronization object is met first, the target task resumes normally upon wakeup; if the waiting deadline arrives first and the synchronization trigger condition is still not met, the target task resumes after a timeout.

[0050] When the waiting deadline in the scheduling list arrives, the task management program reads the coroutine status record of the target task and calls the target task's task entry function. When the synchronization trigger condition corresponding to the waiting state is met, the task management program also calls the same task entry function. The two types of trigger entry points are consistent, differing only in the recovery reason in the waiting condition information. After the task entry function is called, it does not re-execute from the initial business path, but instead enters the execution branch corresponding to the source code line number through the recovery status value. The execution branch continues to read the waiting condition information and determines the waiting return result based on the current time, the waiting deadline, and the fulfillment of the synchronization trigger condition. During normal wake-up, the business code continues to process the data or resources provided by the synchronization object; when the wait times out, the business code executes the timeout handling branch or re-enters the waiting state. If the target task is woken up by the synchronization trigger condition, the task management program needs to remove the target task from the synchronization object's waiting list before calling the task entry function or before executing at the recovery position to prevent the same target task from being woken up repeatedly.

[0051] For delayed waiting scenarios, the arrival of the waiting deadline in the scheduling list serves as the basis for re-calling the task entry function. For synchronous waiting scenarios, the scheduling list and the waiting state can coexist. The scheduling list handles timeout boundaries, while the waiting state handles synchronous wake-ups. If the synchronous triggering condition has been met, the task management program can remove the target task from the scheduling list to avoid repeated calls when the waiting deadline arrives. If the waiting deadline has arrived and the synchronous triggering condition has not been met, the task management program can remove the target task from the waiting state and write the waiting timeout result into the waiting condition information. This process ensures that only one recovery action is generated for the same waiting process. After the target task completes its recovery execution, whether it enters the waiting state again is determined by the next coroutine pause statement in the task body. If the target task no longer waits, the coroutine state record can be cleared when the task execution ends, the recovery state value returns to its initial value, and the waiting condition information is released or reset.

[0052] like Figure 4 As shown, in response to the arrival of the waiting deadline or the fulfillment of the synchronization trigger condition, the task entry function is called, the execution branch is restored according to the recovery status value, and the target task continues to be executed according to the waiting condition information.

[0053] When the waiting deadline arrives or the synchronization trigger condition is met, the task management program identifies the target task as a task that can be called again and invokes the target task's entry function. The task entry function reads the recovery status value from the coroutine status record, locates the source code line number written during the previous pause based on the recovery status value, and enters the execution branch matching that line number. After the target task resumes execution, it continues to read the waiting condition information to determine whether the resumption was triggered by the arrival of the waiting deadline or by the fulfillment of the synchronization trigger condition. After the waiting condition information provides the reason for the resumption, the target task continues executing business statements at the resumption point, without repeating the code already completed before the pause. After resumption, the task can either continue executing business processing or re-enter the pause process based on new waiting statements.

[0054] The target task continues to be executed based on the waiting condition information, including: if the waiting condition information includes a synchronization trigger condition and a waiting deadline, and the current time is earlier than the waiting deadline, the synchronization trigger condition is detected to be met, and the waiting return result is determined to be a normal wake-up; if the waiting condition information includes a synchronization trigger condition and a waiting deadline, and the synchronization trigger condition is not detected to be met when the current time has reached or exceeded the waiting deadline, the waiting return result is determined to be a waiting timeout; and the target task continues to be executed based on the waiting return result.

[0055] In one embodiment, the process of determining the return result is further limited to branching based on the synchronization trigger condition and the waiting deadline in the waiting condition information. This limitation is used to distinguish between normal wake-up and waiting timeout in the synchronous waiting scenario. When the target task executes to the synchronous waiting statement, the task management program has already written the synchronization trigger condition and the waiting deadline into the waiting condition information and marked the target task as waiting. The synchronization trigger condition can correspond to conventional synchronization situations such as semaphore release, message reception in the queue, event flag satisfaction, and availability of mutual exclusion resources. The waiting deadline is used to limit the longest waiting boundary for the target task to wait for the synchronization trigger condition, preventing the target task from being permanently suspended due to the synchronization condition not being met for a long time. The waiting deadline is determined by the longest waiting duration passed in the synchronous waiting statement and the system time base. The system time base can be a monotonic count value maintained by the scheduler, and the counting unit is determined according to the target platform as milliseconds, microseconds, or system ticks.

[0056] When the task entry function is called again because the synchronization trigger condition is met, the recovery process enters the execution branch corresponding to the source code line number. At the recovery location, the waiting condition information is read again to obtain the detection result of the synchronization trigger condition and the waiting deadline. If the current time is earlier than the waiting deadline, and the synchronization trigger condition has been detected as met, the task management program determines that the waiting return result is a normal wake-up. A normal wake-up means that the target task has acquired available resources or event notifications provided by the synchronization object before the timeout boundary is reached. The target task performs business processing based on the waiting return result of the normal wake-up, such as reading messages in the queue, parsing serial port data, acquiring shared resources protected by semaphores, or consuming business events corresponding to event flags. The waiting return result is provided to the target task at the recovery location, and the target task enters the normal business branch accordingly, instead of entering the timeout processing branch.

[0057] If the current time reaches or exceeds the waiting deadline, and the synchronization trigger condition is still not met, the task management program determines the waiting result as a timeout. A timeout indicates that the synchronization object did not meet the recovery condition within the longest waiting boundary. The target task performs timeout processing based on the timeout result, which may involve restarting the wait, recording the error status, skipping the current business processing, or executing degradation logic. If the current time reaches or exceeds the waiting deadline while the synchronization trigger condition has already been met, the recovery reason can be determined based on the recorded time of the synchronization object's state change in the implementation. If the system does not record the synchronization object's state change time, it can be agreed that the synchronization trigger condition should be checked first when entering the recovery branch, and if the check result is met, normal wake-up processing should be performed. This agreement needs to be consistent in the task management program to avoid different return results for the same waiting process on different platforms.

[0058] After the return result is generated, the target task continues executing the code after the recovery position. The wait condition information is only used for the current recovery judgment. If the target task executes the synchronous wait statement again in a subsequent process, the new wait deadline and synchronization trigger condition will overwrite the previous wait condition information. To prevent the target task from being repeatedly woken up, the task management program removes the target task from the wait set or scheduling list of the synchronization object after determining a normal wake-up or wait timeout. The removal action can be completed before calling the task entry function or after the recovery branch determines the wait return result, but a fixed order must be maintained within the same implementation. This ensures that one synchronous wait corresponds to only one recovery execution, avoiding the wait deadline and synchronization trigger condition triggering two separate calls to the task entry function.

[0059] The method also includes: resetting the recovery status value to the initial value and clearing the waiting condition information when the target task has finished executing.

[0060] In one embodiment, the coroutine state record is cleared upon completion of the target task. This limitation ensures that the target task will not reuse the old recovery position when it is started again or re-enters the task entry function. The completion of the target task can be determined by the task entry function reaching its end statement, the task management program receiving a stop command, the completion of the business process, or an abnormal path. After task execution, the task management program resets the recovery state value to its initial value and clears the waiting condition information. The initial value can be zero, null, or an invalid line number as defined by the system. This initial value should be distinguishable from any valid source code line number. When the task entry function reads the initial value, it executes the target task according to the initial position without entering the previous execution branch. After the waiting condition information is cleared, the original waiting deadline, synchronization trigger condition, waiting type, and waiting return result no longer participate in subsequent recovery decisions.

[0061] When resetting the status value, the task management program must ensure that the target task is no longer attached to the scheduling list or the waiting set of a synchronization object. If the target task is canceled by the business process before the waiting deadline arrives, the task management program removes the record associated with the target task and the waiting deadline from the scheduling list. If the target task is in a waiting state and is attached to a synchronization object, the task management program removes the target task from the waiting set of the corresponding synchronization object to prevent the completed task entry function from being called again when the synchronization trigger condition is subsequently met. If the target task has both a record in the scheduling list and a record attached to a synchronization object, both types of records need to be cleaned up. The cleanup order can be determined according to the system implementation, but after cleanup, the target task must not be triggered by any old waiting condition again.

[0062] Clearing wait condition information can be achieved by resetting fields. The wait deadline field is reset to an invalid time value, the synchronization trigger condition field is reset to an empty condition, and the wait return result field is reset to a no-result state. If the coroutine status record is stored in a static structure, the clearing operation directly rewrites the structure fields, without needing to release dynamic memory. If the system maintains a wait list for synchronization objects, the clearing operation should also update the list pointer or task index to keep the wait list intact. In resource-constrained microcontroller environments, a static task table and a fixed-length wait queue can be used to store the above data, avoiding heap memory release failures or fragmentation issues when tasks end.

[0063] When the target task is called again after its execution, the task entry function reads the reset recovery state value and executes the target task from the initial position. This isolates two complete runs of the same target task, preventing source code line numbers saved during the previous run from affecting the next run. If an exception occurs when the target task finishes execution, such as business processing failure, synchronization object failure, or incomplete wait condition information, the task management program can still reset the recovery state value and clear the wait condition information to ensure that the next call can start from a stable state. The cause of the exception can be recorded in the log or error code by the business layer. The coroutine state record only retains the data necessary for recovery control and does not carry complex business error information. This cleanup process, in conjunction with the line number recovery process, ensures that the target task has clear state boundaries in the pause, recovery, and termination phases.

[0064] This embodiment uses an embedded serial port data receiving task as an example to illustrate the coroutine recovery method based on line number status. The target device can be an embedded control board with a microcontroller. The microcontroller runs a lightweight task management program, which maintains a static task table, a scheduling list, and a synchronization object table. The static task table assigns a task record to each target task, which includes a task entry function pointer, a coroutine status record, a task running flag, and synchronization object attachment information. The coroutine status record includes a recovery status value and waiting condition information. The recovery status value stores the source code line number when the target task exits, and the waiting condition information stores the waiting deadline, the synchronization trigger condition, and the waiting return result. The waiting deadline uses the system time base record maintained by the task management program, which can be a millisecond count. In this embodiment, the synchronization trigger condition is the release of a semaphore, which indicates that there is parseable data in the serial port receive buffer.

[0065] The task entry function for the serial port data reception task is named the "Serial Port Task Entry Function," and it is called by the task management program according to the task scheduling results. Only one serial port data reception task is instantiated in the source file containing the serial port task entry function, and the recovery status value records the actual line number in that source file. The task entry function internally sets up a status selection structure. This structure uses a switch statement to receive the recovery status value as the branch selection value, with multiple case branches corresponding to the actual line numbers of the coroutine pause statements in the source file. When the recovery status value is the initial value, the task entry function does not enter the line number recovery branch but executes from the initial position. When the recovery status value is not the initial value, the task entry function matches the recovery status value with the line numbers corresponding to each case branch. If a match is successful, it directly enters the corresponding branch and continues execution from the position corresponding to that line number in the source code.

[0066] When the system powers on, the task management program initializes the task record corresponding to the serial port data receiving task. The recovery status value is set to the initial value, the waiting deadline is set to an invalid time value, the synchronization trigger condition is set to an empty condition, and the waiting return result is set to a no-result status. When the serial port task entry function is called for the first time, it reads the coroutine status record of the serial port data receiving task. Since the recovery status value is the initial value, the task entry function executes from the initial position, completing the serial port peripheral initialization, receive buffer initialization, and semaphore binding. Serial port peripheral initialization includes configuring the serial port baud rate, data bits, stop bits, parity mode, and receive interrupt enable. Receive buffer initialization includes clearing the circular buffer read / write positions and resetting the receive data count to zero. Semaphore binding is used to ensure that the serial port receive interrupt or receive callback releases the semaphore after writing data, thereby waking up the serial port task waiting for data.

[0067] After initialization, the serial port task entry function enters the task loop. The task loop waits for serial data to arrive, using a synchronous wait statement to wait for the serial port receive semaphore. The maximum wait time in the synchronous wait statement is configured to be 10 milliseconds. When the task execution reaches the location of the synchronous wait statement, the coroutine pause logic is triggered. The synchronous wait statement reads the actual source code line number at the current location, for example, line 126 in the source file, and writes this line number into the recovery status value. The synchronous wait statement writes the release of the semaphore as a synchronization trigger condition into the wait condition information, and generates a wait deadline based on the current system time base and the 10-millisecond maximum wait time. After writing, the task management program marks the serial port data reception task as waiting, attaches the task to the wait set of the serial port receive semaphore, and stores the task and wait deadline in the scheduling list. The serial port task entry function then returns to the caller, and the processor does not execute a blocking loop in this task.

[0068] When a serial port receive interrupt receives data, the received byte is written to the circular receive buffer. If the receive buffer changes from empty to non-empty, the bottom half of the serial port receive interrupt or the callback function releases the serial port receive semaphore. After detecting this semaphore release, the task manager checks the target tasks attached to the semaphore waiting set. If the serial port data receive task is in a waiting state, and the synchronization trigger condition in the waiting condition information is semaphore release, the task manager switches the serial port data receive task from the waiting state to the callable state. If this task also has a waiting deadline record in the scheduling list, the task manager can remove the waiting deadline record to avoid repeatedly calling the same task entry function when 10 milliseconds have elapsed.

[0069] When the serial port task entry function is called again, it reads the coroutine status record of the serial port data receiving task. At this time, the restored status value is line 126, which is a non-initial value. The task entry function inputs line 126 as the branch selection value into the switch statement. The status selection structure matches the case branch corresponding to line 126, and the program enters that branch. This branch is located after the synchronization wait statement, so the task does not re-execute the serial port initialization, nor does it re-enter the business statements before the wait statement. The restored branch reads the wait condition information, obtaining the wait deadline and the status of the synchronization trigger condition. The current time is earlier than the wait deadline, and the serial port receive semaphore has been released. The task management program determines the wait return result as a normal wake-up. The serial port task continues execution based on the normal wake-up result, reading data from the circular receive buffer, parsing the data frame header, length field, and checksum field. If the data frame is complete, the serial port data parsing function is called to process the received data; if the data frame is incomplete, the received content is retained, and the task loop re-enters the synchronization wait statement.

[0070] In another operating scenario, the serial port receive buffer receives no data within 10 milliseconds. The scheduler checks that the waiting deadline associated with the serial port data receive task in the scheduling list has been reached, identifies the serial port data receive task as a callable task, and calls the serial port task entry function. After reading the recovery status value, the task entry function also enters the case branch corresponding to line 126. The recovery branch reads the waiting condition information and makes a judgment. If the current time has reached or exceeded the waiting deadline, and the synchronization trigger condition has not been met, the task management program determines the waiting return result as a timeout. Based on the timeout result, the serial port task does not execute the serial port data parsing function, but instead enters the timeout handling branch. The timeout handling branch can perform receive status checks, count timeouts, clean up invalid half-frame data, or directly return to the task loop to continue waiting. If the service requires low power consumption, the timeout handling branch may not perform any additional service actions, but only re-enter the synchronization wait statement, allowing the task to continue waiting for serial port data in a non-blocking manner.

[0071] Once the serial port task completes its current business processing at the recovery point, the task loop continues running. If the task loop executes a synchronous wait statement again, the coroutine pause logic rewrites the current source code line number, synchronization trigger condition, and new wait deadline. The old wait condition information is overwritten by the new wait condition information, and the recovery status value continues to store the source code line number before the most recent exit. In this way, each wait process corresponds to only one recovery status value and one set of wait condition information, avoiding multiple wait processes from sharing the same status.

[0072] If a stop command is received during the execution of a serial port task, the task management program sets the serial port data receiving task to the end process. When the task entry function reaches the end processing position, it clears the coroutine state record, resets the recovery state value to its initial value, restores the waiting deadline to an invalid time value, restores the synchronization trigger condition to an empty condition, and restores the waiting return result to a no-result state. If the task is still attached to the semaphore waiting set, the task management program removes the task from the waiting set; if the task still exists in the scheduling list record, the task management program deletes the record. After the cleanup is completed, when the serial port task is called again, it will execute from the initial position and will not enter the execution branch corresponding to the old source code line number. This process can prevent the line number state saved during the previous execution from affecting the start of the next task.

[0073] In this embodiment, the recovery status value is only used to record the actual line number in the source file where the serial port task entry function is located, and is not used to save the complete thread stack. The task does not occupy processor execution time during the waiting period, nor does it require maintaining a manual status number for each waiting point. Intermediate business data that needs to be retained across pause points, such as the circular buffer pointer, the length of received data, and the verification status, are saved by the serial port task's own context or static buffer. The coroutine status record only saves the data required for recovery control, namely the source code line number, the waiting deadline, the synchronization trigger condition, and the waiting return result. This boundary makes the state recovery mechanism independent of business data management, facilitating deployment in microcontrollers with limited storage resources.

[0074] An electronic device includes a processor and a memory, the memory storing at least one computer program, the at least one computer program being loaded and executed by the processor to implement a coroutine recovery method based on line number state.

[0075] Electronic devices can be embedded control boards, microcontroller development boards, industrial control terminals, vehicle controllers, intelligent peripheral controllers, or other computing devices capable of executing task management programs. Electronic devices include processors and memory. The processor can be a microcontroller, digital signal processor, system-on-a-chip processor, or general-purpose processor. Memory can include non-volatile memory and volatile memory. Non-volatile memory is used to store the task management program, serial port task entry function, coroutine recovery program code, and related configuration data. Volatile memory is used to store static task tables, scheduling lists, synchronization object tables, coroutine status records, circular receive buffers, and task running flags during program execution.

[0076] The memory stores at least one computer program. When the processor loads and executes this computer program, it can perform the aforementioned coroutine recovery method based on line number status. Specifically, when the task entry function of the target task is called, the processor reads the coroutine status record; when the recovery status value is the initial value, it executes the target task from the initial position; when the recovery status value is not the initial value, it enters the execution branch corresponding to the source code line number according to the recovery status value; when the target task executes to the coroutine pause statement, it writes the source code line number corresponding to the coroutine pause statement into the recovery status value, writes at least one of the waiting deadline and synchronization trigger condition into the waiting condition information, and exits the task entry function; when the waiting deadline is reached or the synchronization trigger condition is met, the processor calls the task entry function again, recovers to the execution branch according to the recovery status value, and continues to execute the target task according to the waiting condition information.

[0077] In the implementation of the embedded serial port data receiving task, the electronic device may also include a serial port interface, a timer, an input / output interface, or an interrupt controller. The serial port interface is used to receive external serial port data. The serial port receive interrupt writes the received data into a circular receive buffer and releases the serial port receive semaphore. The timer or system time base provides the basis for determining the waiting deadline. When the processor executes the task management program, it determines whether to call the serial port task entry function again based on the scheduling list and the synchronization object table. After the serial port task entry function is called again, it enters the corresponding execution branch based on the recovery status value in the coroutine status record and determines whether the recovery is a normal wake-up or a timeout based on the waiting condition information. The specific hardware form of the electronic device does not affect the implementation of the above method; as long as it can provide program execution, state storage, and waiting condition triggering capabilities, it can serve as the execution carrier of this embodiment.

[0078] A computer-readable storage medium storing at least one computer program, which is loaded and executed by a processor to implement a line number-based coroutine recovery method.

[0079] A computer-readable storage medium can be a storage medium capable of being read and loaded by a processor to create a computer program. The computer-readable storage medium stores at least one computer program that, when loaded and executed by the processor, implements the aforementioned line-number-based coroutine recovery method. The computer-readable storage medium can include read-only memory, random access memory, flash memory, embedded multimedia memory, solid-state memory, disk storage, optical disk storage, or other non-volatile or volatile storage media capable of storing program code. The computer program can be in the form of source code, object code, executable file, or other program code forms capable of being compiled, interpreted, loaded, and executed.

[0080] In one implementation, the computer program stored in the computer-readable storage medium includes a task entry function call program, a coroutine state record reading program, a line number recovery program, a wait condition writing program, a scheduling trigger program, and a state cleanup program. The task entry function call program is used to enter the task entry function of the target task when the target task meets the scheduling conditions. The coroutine state record reading program is used to read the recovery state value and wait condition information. The line number recovery program is used to enter the execution branch corresponding to the source code line number based on the recovery state value. The wait condition writing program is used to write the source code line number, wait deadline, or synchronization trigger condition when the target task execution reaches the coroutine pause statement. The scheduling trigger program is used to call the task entry function again when the wait deadline is reached or the synchronization trigger condition is met. The state cleanup program is used to reset the recovery state value and clear the wait condition information when the target task execution ends.

[0081] Once the computer program in the computer-readable storage medium is deployed to an electronic device, the electronic device can perform the pause, exit, wait, and resume of the target task according to the process described in the foregoing embodiments. For resource-constrained microcontrollers, the computer program can be stored in on-chip flash memory, and during runtime, coroutine state records and wait condition information can be saved in a static memory area. For electronic devices with an operating system, the computer program can be stored as part of an application program, firmware program, or driver program, and during processor execution, it can call system timers, synchronization objects, or task scheduling interfaces to implement the same coroutine resumption process. The implementation of the computer-readable storage medium described above belongs to the same technical concept as the foregoing method embodiments; implementation details not described in detail can be found in the relevant content of the foregoing line number-based coroutine resumption method.

[0082] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects.

[0083] The above are merely embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various modifications, equivalent substitutions, and improvements within the spirit and principles of the present invention.

Claims

1. A coroutine recovery method based on row number status, characterized in that, The method includes: In response to the task entry function of the target task being called, the coroutine status record of the target task is read. The coroutine status record includes a recovery status value and waiting condition information. The recovery status value records the source code line number when the target task exits. When the recovery state value is the initial value, the target task is executed from the initial position; When the recovery status value is not the initial value, the execution branch corresponding to the source code line number is entered according to the recovery status value; When the target task executes to the coroutine pause statement, the source code line number corresponding to the coroutine pause statement is written into the recovery status value, at least one of the waiting deadline and synchronization triggering conditions is written into the waiting condition information, and the task entry function is exited. In response to the arrival of the waiting deadline or the fulfillment of the synchronization triggering condition, the task entry function is invoked, the execution branch is restored according to the recovery status value, and the target task continues to be executed according to the waiting condition information.

2. The method according to claim 1, characterized in that, The source code line number is the actual line number in the source file where the target task is located, and the task entry function has an execution branch corresponding to the source code line number.

3. The method according to claim 2, characterized in that, Entering the execution branch corresponding to the source code line number includes: Use the recovery status value as the branch selection value of the switch statement; If the branch selection value matches the source code line number corresponding to the case branch, enter the case branch to continue executing the target task from the position corresponding to the source code line number.

4. The method according to claim 1, characterized in that, The coroutine pause statements include delayed wait statements and synchronous wait statements; The delay / wait statement is used to instruct the target task to wait until the waiting deadline is reached; The synchronization wait statement is used to instruct the target task to wait for the synchronization triggering condition to be met, and to set the waiting deadline.

5. The method according to claim 4, characterized in that, The step of writing at least one of the waiting deadline and the synchronization triggering condition into the waiting condition information includes: If the target task reaches the point where the delay wait statement is executed, the wait deadline is written into the wait condition information; When the target task reaches the synchronous wait statement, the synchronous trigger condition and the wait deadline are written into the wait condition information.

6. The method according to claim 1, characterized in that, After exiting the task entry function, the method further includes: If the waiting condition information includes the waiting deadline, the target task is associated with the waiting deadline and stored in the scheduling list; If the waiting condition information includes the synchronization triggering condition, the target task is marked as waiting, and the waiting state is used to indicate that the target task is waiting for the synchronization triggering condition to be met; In response to the arrival of the waiting deadline in the scheduling list, or the fulfillment of the synchronization trigger condition corresponding to the waiting state, the task entry function is invoked again.

7. The method according to claim 6, characterized in that, The step of continuing to execute the target task based on the waiting condition information includes: If the synchronization trigger condition is detected to be met when the waiting condition information includes the synchronization trigger condition and the waiting deadline, and the current time is earlier than the waiting deadline, the waiting return result is determined to be a normal wake-up. If the waiting condition information includes the synchronization trigger condition and the waiting deadline, and the synchronization trigger condition is not detected to be satisfied when the current time reaches or exceeds the waiting deadline, the waiting return result is determined to be a waiting timeout. The target task will continue to be executed based on the expected return result.

8. The method according to claim 1, characterized in that, The method further includes: Upon completion of the target task, the recovery status value is reset to the initial value, and the waiting condition information is cleared.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory, the memory storing at least one computer program, which is loaded and executed by the processor to implement the line number-based coroutine recovery method as described in any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one computer program, which is loaded and executed by a processor to implement the line number-based coroutine recovery method as described in any one of claims 1 to 8.

Images