Task Synchronization Waiting Method, Device, System, Electronic Device, and Storage Medium

Abstract

An embodiment of the present invention provides a task synchronization waiting method, which splits a service to be processed into a first number of driving tasks and adds them to a second number of flow task queues; adds event dependencies to the driving tasks, and the event dependencies include parallel synchronization waiting events between different flow task queues; executes the event dependencies to enable the flow task queues to achieve parallel synchronization waiting. By splitting the service to be processed into multiple driving tasks and then converting the driving tasks into driving task flows and adding them to multiple flow task queues, the scheduling between multiple threads is converted into the scheduling between flows, and event dependencies are used to achieve the parallel waiting of multiple flow task queues, so as to achieve task synchronization waiting based on flow task queues. Compared with the direct scheduling between multiple threads, the system scheduling overhead is reduced.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular, to a task synchronization waiting method, device, system, electronic device, and storage medium. Background Art

[0002] With the development of computer technology, in the aspect of solving a large amount of data computing, parallel computing is usually used to improve the computing speed. Parallel computing needs to use a variety of computing resources to solve computing problems, and the computing resources include hardware acceleration units, neural network computing units, CPU units, DSP units, etc. At present, the parallel computing scheduling mainly uses multi-threading and inter-thread message queues for scheduling. However, due to too many threads, the parallel computing scheduling will cause too large an operating system scheduling overhead, and multiple threads need to wait for the completion of parallelism. If additional computing units are added to improve the operating system scheduling ability, due to the high dependence between software and hardware, the process of adding computing units is cumbersome and requires various complex configurations, making the expansion difficult. Therefore, in the prior art, the scheduling efficiency of multi-threaded computing resources is low. Summary of the Invention

[0003] An embodiment of the present invention provides a task synchronization waiting method. By splitting the service to be processed into multiple driving tasks, and then converting the driving tasks into a driving task flow and adding it to multiple flow task queues, the scheduling between multiple threads is converted into the scheduling between flows, and event dependencies are used to achieve parallel waiting of multiple flow task queues, thereby realizing task synchronization waiting based on flow task queues. Compared with the direct scheduling between multiple threads, the system scheduling overhead is reduced.

[0004] In a first aspect, an embodiment of the present invention provides a task synchronization waiting method, and the method includes:

[0005] Split the service to be processed into a first number of driving tasks and add them to a second number of flow task queues, and the second number of flow task queues are in a parallel relationship;

[0006] Add event dependencies to the driving tasks, and the event dependencies include parallel synchronization waiting events between different flow task queues;

[0007] Execute the event dependencies to enable the flow task queues to achieve parallel synchronization waiting.

[0008] In a second aspect, an embodiment of the present invention provides a task synchronization waiting device, and the device includes:

[0009] A splitting module, configured to split the service to be processed into a first number of driving tasks and add them to a second number of flow task queues, and the second number of flow task queues are in a parallel relationship;

[0010] An adding module, configured to add event dependencies to the drive tasks, where the event dependencies include parallel synchronization waiting events between different flow task queues;

[0011] An execution module, configured to execute the event dependencies, so that the flow task queues achieve parallel synchronization waiting.

[0012] In a third aspect, an embodiment of the present invention provides a task synchronization waiting system, where the system includes: an application layer, a flow scheduling layer, and a drive layer. Among them, the application layer is configured to generate drive tasks and receive drive task results, the drive layer is configured to provide drive to calculate the drive tasks, and the flow scheduling layer is configured to implement the steps in the task synchronization waiting method provided by the embodiment of the present invention.

[0013] In a fourth aspect, an embodiment of the present invention provides an electronic device, including: a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the steps in the task synchronization waiting method provided by the embodiment of the present invention are implemented.

[0014] In a fifth aspect, an embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps in the task synchronization waiting method provided by the embodiment of the invention are implemented.

[0015] In the embodiment of the present invention, the service to be processed is split into a first number of drive tasks and added to a second number of flow task queues; event dependencies are added to the drive tasks, and the event dependencies include parallel synchronization waiting events between different flow task queues; the event dependencies are executed to enable the flow task queues to achieve parallel synchronization waiting. By splitting the service to be processed into multiple drive tasks and then converting the drive tasks into a drive task stream and adding it to multiple flow task queues, the scheduling between multiple threads is converted into the scheduling between flows, and event dependencies are used to achieve the parallel waiting of multiple flow task queues, thereby realizing task synchronization waiting based on flow task queues. Compared with the direct scheduling between multiple threads, the system scheduling overhead is reduced. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can be obtained based on these drawings without creative efforts.

[0017] Figure 1 It is an architecture diagram of a task synchronization waiting system provided by an embodiment of the present invention;

[0018] Figure 2 It is a schematic diagram of the state of a flow scheduling provided by an embodiment of the present invention;

[0019] Figure 3 It is another schematic diagram of the state of a flow scheduling provided by an embodiment of the present invention;

[0020] Figure 4 It is a schematic diagram of task splitting of a graph service graph provided by an embodiment of the present invention;

[0021] Figure 5 It is a schematic diagram of a parallel flow task queue of a graph service graph provided by an embodiment of the present invention;

[0022] Figure 6 It is a flowchart of a task synchronization waiting method provided by an embodiment of the present invention;

[0023] Figure 7 It is a schematic diagram of creating event dependencies of a parallel flow task queue provided by an embodiment of the present invention;

[0024] Figure 8 It is a schematic diagram of CLStream synchronization waiting provided by an embodiment of the present invention;

[0025] Figure 9 It is a schematic diagram of CLEvent synchronization waiting provided by an embodiment of the present invention;

[0026] Figure 10 It is a schematic diagram of the structure of a task synchronization waiting device provided by an embodiment of the present invention;

[0027] Figure 11 It is a schematic diagram of the structure of an electronic device provided by an embodiment of the present invention. Detailed implementation manners

[0028] Next, the technical solutions in the embodiments of the present invention will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, rather than all the embodiments. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present invention without making creative efforts shall fall within the protection scope of the present invention.

[0029] Please refer to Figure 1 , Figure 1 which is an architecture diagram of a task synchronization waiting system provided by an embodiment of the present invention, as Figure 1As shown in the figure, the task synchronization waiting system includes: an application layer, a stream scheduling layer, and a driver layer. Among them, the above application layer includes one or more application threads, the above stream scheduling layer includes one or more stream scheduling threads, and the above driver layer includes multiple drivers.

[0030] In the embodiment of the present invention, the above application thread includes an application module and an interface module CLAPI. Among them, the above interface module CLAPI includes a CLSignal (Computing Language Signal) thread management interface unit, a CLStream (Computing Language Stream) stream management interface unit, and a CLEvent (Computing Language Event) event management interface unit. The above CLSignal thread management unit is used for synchronization waiting between multiple threads; the above CLStream stream management unit is used to provide management interfaces for creating and destroying a stream task queue; the above CLEvent management unit is used for synchronization waiting between parallel computations. Among them, the above CLEvent management unit includes a SchedEvent (Scheduler Event) scheduling event, and the scheduling event is used for the stream scheduling unit to synchronize states. One CLEvent management unit can correspond to multiple SchedEvent scheduling events.

[0031] The above application layer generates corresponding driver tasks and driver task results according to the service to be processed, and sends corresponding management instructions to the above stream scheduling layer through the interface module. The above driver layer is used to provide a driver to calculate the above driver task and return a driver response task to the task distribution unit. The above stream scheduling layer is used to obtain a driver task from the application layer. The above driver task includes a control task and a driver request task; based on the above control task, the above driver request task is converted into a driver task stream and added to the stream task queue; based on the above driver response task, the above driver task stream in the above stream task queue is driven and distributed; the distributed driver is matched from the driver layer to process the above driver task stream, and a driver response task is returned to the above stream scheduling layer.

[0032] Specifically, the above stream scheduling thread includes a task queue, a task distribution unit, a stream control management unit, a stream task queue, a stream scheduling unit, a driver distribution unit, a driver information storage unit, a driver information registration unit, an event database unit, and an Event management unit. Among them, the above driver information storage unit can be in the form of a driver information table, and the above event database unit can be in the form of an event information table.

[0033] Among them, the input of the above task queue is connected to the output of the above application thread, and is used to store the driver tasks generated by the application thread, the driver response tasks returned by the driver layer, and the event tasks generated by the CLSignal thread management interface unit and the CLEvent event management interface unit according to the first-in-first-out rule. The input of the above task distribution unit is connected to the output of the above task queue, and the above task distribution unit is used to distribute each task in the task queue to the flow control management unit, the flow task queue, the flow scheduling unit, and the Event management unit. The output of the above flow scheduling unit is connected to the input of the driver distribution unit, and the above driver distribution unit is used to query the information in the driver storage unit, and the output of the above driver distribution unit is connected to the input of the above driver layer. The above driver information registration unit is used to register the drivers in the driver layer and store the registration information of each driver in the above driver storage unit.

[0034] The above CLSignal thread management interface unit and the above CLEvent event management interface unit generate corresponding event tasks and event control instructions. Among them, the above event tasks are forcibly converted into stream data and added to the task queue, and are distributed to the flow task queue through the task distribution unit. The above event control instructions are distributed to the Event event management unit through the task distribution unit.

[0035] Further, the above task distribution unit issues tasks according to the task types in the task list. Specifically, the above task types include driver task types, driver response tasks, event task types, and event control instruction types. The above driver task types include control tasks and driver request tasks. Among them, the above control task can also be called a flow control instruction. The above task distribution unit distributes the above driver request tasks and event tasks to the flow task queue, the above task distribution unit distributes the above control tasks to the flow control management unit, the above task distribution unit distributes the driver response tasks to the flow scheduling unit, and the above task distribution unit sends the above event control instructions to the Event event management unit.

[0036] Among them, the above control tasks are mainly commands for creating and destroying flows, and the control tasks are forwarded by the above task distribution unit to the flow control management unit for processing. Further, the above flow control management unit creates and destroys flows according to the above control tasks.

[0037] Optionally, when creating a flow, the above flow control management unit can detect the maximum number of flows. If the maximum number of the created flow task queue exceeds the preset creation quantity threshold, it returns a failure to the application layer. When destroying the flow task queue, the above flow control management unit can detect whether there are unfinished driver task flows. If there are unfinished driver task flows, it returns a failure to the application layer. Meanwhile, the above flow control management unit can also detect in real time whether the number of driver task flows in the above flow task queue exceeds the preset task quantity threshold. If it exceeds, it can trigger upper-layer flow control to block the application line layer of the application layer.

[0038] The above driver request task is mainly a task for the upper-layer user to request driver processing calculation through the flow scheduling unit. According to the flow task queue where the task is located, the driver request task is written to the tail of the flow task queue to obtain a first-in, first-out flow.

[0039] Optionally, after receiving the driver request task, event task, and driver response task, the above flow scheduling unit will trigger the task scheduling of the flow. The above flow scheduling unit can be implemented by using a state machine. Specifically, the state machine includes the flow in the flow scheduling process in an executable state, a state of waiting for the driver to complete, a state of waiting for the driver resources to be available, and a state of waiting for the event to complete.

[0040] The above driver response task is mainly sent to the flow scheduling unit through the driver task completion status auxiliary information after the driver is completed, and the flow scheduling unit triggers the processing of the subsequent driver request task of the flow.

[0041] The above driver distribution unit receives the driver request task of the flow scheduling unit, parses the driver id (driver identifier) of the driver request task, and searches for the matching driver registration information in the driver storage unit according to the driver id.

[0042] In a possible embodiment, there is one above flow scheduling thread. It can be understood that the above flow scheduling is implemented by using an independent thread. Through the above independent flow scheduling thread, the above application thread and driver thread are decoupled, so that the above task synchronization waiting system of the embodiment of the present invention can be extended by configuring the flow task queue and the driver.

[0043] Further, in the case of implementing flow scheduling using independent threads, a preset number of flow task queues can be scheduled in parallel. For example, 1024 flow task queues can be scheduled in parallel. Any time-consuming processing inside will seriously affect the scheduling efficiency. The flow scheduling thread can be prohibited from executing any other computing tasks. The driver layer can be designed as a driver thread. The general driver processing function (which can also be called the driver task synchronization waiting function) registered in the driver_register_table (driver information storage unit) will forward the driver request task in the flow scheduling to the driver thread for processing.

[0044] Optionally, please refer to Figure 2 , Figure 2 which is a schematic diagram of the state of a flow scheduling provided by an embodiment of the present invention. As Figure 2 shown, when the above flow scheduling unit performs scheduling processing, it can take out the driver task flow from the head of the flow task queue and hand it over to the above driver distribution unit for processing. The above driver distribution unit receives the driver task flow from the flow scheduling unit, parses the driver id of the driver request task, searches for the matching driver registration information in the driver storage unit according to the driver id, and calls the driver load query function through the above driver distribution unit to query the load status of the driver corresponding to the driver id.

[0045] If the load of the driver corresponding to the driver id is high, it means that the driver corresponding to the driver id is in a busy state, then the driver state is returned as unavailable (failed) to the above flow scheduling unit, and the above flow scheduling unit marks the driver task flow as waiting for the driver resource to be available; if the load of the driver corresponding to the driver id is low, it means that the driver corresponding to the driver id is in an available state, then the driver state is returned as available to the above flow scheduling unit, and the above flow scheduling unit marks the driver task flow as waiting for the driver to complete, and records the auxiliary information of the driver task completion state that the driver task flow is waiting for (the driver state is executable). If the auxiliary information of the driver task completion state is received, the driver task flow waiting for the auxiliary information of the driver task completion state is found, and the state of the driver task flow is switched to the executable state; further, all driver task flows waiting for the driver resource to be available can be traversed, and according to the driver id waiting for the resource, the driver load query function is called through the driver distribution unit to query the load status of the driver corresponding to the driver id. If the query shows that the driver load is low, then the state of the driver task flow is switched from the waiting for the driver resource to be available state to the executable state.

[0046] The above driver distribution unit can allocate the auxiliary information resources of the driver task completion state for the driver task flow, and call the driver processing function to control the driver to process the above driver task flow.

[0047] Optionally, please refer to Figure 3 , Figure 3This is another state diagram of flow scheduling provided by an embodiment of the present invention. As Figure 3 shown, when the above flow scheduling unit performs scheduling processing, on the basis of Figure 2 , the above state machine also adds a waiting event completion state extension. If the event task corresponding to the drive task is not ready, the drive task is marked as the waiting event completion state. If the event task corresponding to the drive task is ready, the drive task is marked as the executable state.

[0048] In the embodiment of the present invention, based on the above task synchronization waiting system, it mainly includes three parts, namely: 1): Synchronization between multiple flow task queues, which is used to solve task dependencies between multiple flow task queues in the flow scheduling unit; 2): CLStream synchronization waiting, which is used to wait for all tasks in a specified flow task queue to complete; 3): CLEvent synchronization waiting, which is used to wait for a specified CLEvent to be scheduled and executed in a specified flow task queue.

[0049] In the embodiment of the present invention, the service to be processed can be split into a first number of drive tasks and added to a second number of flow task queues. The second number of flow task queues are in a parallel relationship; event dependencies are added to the above drive tasks, and the event dependencies include parallel synchronization waiting events between different flow task queues; the above event dependencies are executed to enable the above flow task queues to achieve parallel synchronization waiting. Taking the graph service graph as an example, the three parts are described in detail. Specifically, please refer to Figure 4 , Figure 4 This is a schematic diagram of task splitting of a graph service graph provided by an embodiment of the present invention. As Figure 4 shown, a graph service is split into 8 drive tasks such as a1, b1, c1, a2, b2, c2, a3, and c3. Among them, b1 and c1 are parallel, and a3 and c2 are parallel. For the addition of event dependencies, please refer to Figure 5 , Figure 5 This is a schematic diagram of a parallel flow task queue of a graph service graph provided by an embodiment of the present invention. As Figure 5As shown in the figure, the parallel stream task queue includes stream task queue StreamA, stream task queue StreamB, and stream task queue StreamC. Among them, each stream task queue is synchronized through event task event e1 and event task event e2. The record event and wait event operations of event task event are used for synchronization between streams. For example: The starting position of Stream A is the driving task a1, followed by the record event of event task e1. Stream B and Stream C both wait for the completion of this event task e1 through the wait event of event task e1 at their starting positions, followed by their respective driving tasks b1 and c1. Here, only when Stream A executes the e1 record task (task a1 has been completed) and updates the status of e1, the scheduling of Stream B and C is triggered (waiting for e1).

[0050] In the embodiment of the present invention, the above task synchronization waiting system splits the service to be processed into multiple driving tasks, and then converts the driving tasks into driving task streams and adds them to multiple stream task queues, so that the scheduling between multiple threads is converted into the scheduling between streams, and event dependencies are used to achieve parallel waiting of multiple stream task queues, thereby achieving task synchronization waiting based on stream task queues. Compared with the direct scheduling between multiple threads, the system scheduling overhead is reduced.

[0051] Please refer to Figure 6 , Figure 6 is a flowchart of a task synchronization waiting method provided by an embodiment of the present invention. The above task synchronization waiting method can be applied to the above Figure 1 task synchronization waiting system of the embodiment, as Figure 6 shown, the task synchronization waiting method includes the following steps:

[0052] 601. Split the service to be processed into a first number of driving tasks and add them to a second number of stream task queues.

[0053] In the embodiment of the present invention, the above second number of stream task queues are in a parallel relationship. The service to be processed can be hardware acceleration processing, neural network processing, CPU computing processing, DSP computing tasks, etc.

[0054] Furthermore, the second number of stream task queues can be determined according to the total data volume of the service to be processed; the service to be processed is split into a first number of driving tasks, and the parallel and serial relationships between the driving tasks are configured through the above stream task queues; the parallel driving tasks are correspondingly added to the parallel stream task queues, and the serial driving tasks are configured in the stream task queues.

[0055] Specifically, the data throughput of each stream task queue and the data volume of each driver task can be determined first. The second quantity of the stream task queue is determined by dividing the total data volume of the service to be processed by the data throughput of each stream task queue within the total processing period. In a possible embodiment, the number of driver tasks for each stream queue in one round of the processing period is determined by dividing the data throughput of each stream task queue by the data volume of each driver task, and the total number of driver tasks in the total processing period is calculated as the first quantity.

[0056] 602. Add event dependencies to the driver tasks.

[0057] In the embodiment of the present invention, the above event dependencies include parallel synchronization waiting events between different stream task queues. Further, a record event and a waiting event of the current driver task can be created; the record event of the current driver task is added to the current stream task queue, and the waiting event of the current driver task is added to the parallel queue of the current stream task queue, where the current driver task is located in the current stream queue.

[0058] Specifically, the record event can be added after the current driver task, and the waiting event can be added before the parallel driver task. That is, the driver task in the parallel stream task queue needs to wait for the current driver task in the current stream task queue to complete before processing its own driver task. For details, please refer to the corresponding embodiment again. Figure 5 Corresponding embodiment.

[0059] Optionally, a target event object can be found from the above event database; a time scheduling object is added to the end of the scheduling event list in the target event object, and the initial state of the time scheduling object is unprepared; an event record task of the current stream task queue is generated, and the event record task includes a first time scheduling object pointer that points to the time scheduling object at the end of the scheduling event list; the event record task is added to the end of the current stream task queue as the record event. By adding a time scheduling object to the end of the scheduling event list, the latest target event object in the scheduling event list and the status of the target event object can be quickly found.

[0060] Optionally, a target event object can be found from the above event database; an event waiting task for generating the above parallel stream task queue is created, the above event waiting task includes a second time scheduling object pointer, and the second time scheduling object pointer points to the time scheduling object at the tail of the above scheduling event list; the above event waiting task is added to the tail of the above parallel stream task queue as a waiting event. By adding an event waiting task to the parallel stream task queue, the parallel stream task queue waits for the completion of the processing of the current stream task queue through this event waiting task, and the second time scheduling object pointer can indicate the latest event waiting task in the parallel stream task queue and quickly find the status of the event waiting task.

[0061] Specifically, please refer to Figure 7 , Figure 7 which is a schematic diagram of creating event dependencies for a parallel stream task queue provided by an embodiment of the present invention. As Figure 7 shown, the driving tasks include a1, b1, a2, b2...

[0062] First, the application in the task synchronization waiting system creates 2 streams through the CLStream stream management interface unit, recorded as s1 and s2. The driving tasks a1, a2... are added to s1, and b1, b2... are added to s2. Inside the stream scheduling layer, the stream control management unit controls the creation of two empty stream task queues s1 and s2 corresponding to the stream_task_queues in the stream scheduling layer, completing the creation of s1 and s2 by the CLStream stream management interface unit.

[0063] Secondly, the application creates 1 event task event through the CLEvent event management interface unit, recorded as e1; the Event event management unit in the stream scheduling layer receives the command to create the event task event e1, creates a new empty event event object e1 in the event database event_table. Each event event object contains: a) a record counter for maintaining the event, which can also be called an event counter, recorded as e1.record_count, with an initial value of 0; b) a SchedEvent scheduling event list, recorded as e1.sched_events_state[], and the list is initially empty, completing the creation of CLEvent e1.

[0064] The application sends the driving tasks task in s1 and s2. Specifically, the application can issue them according to the task order of the driving tasks. The event task event mainly includes two step processes of event recording and event waiting, corresponding to the above-mentioned record event and waiting event respectively. The above s2 is the parallel stream task queue of s1.

[0065] Among them, taking the event task e1 record of s1 as described above for illustration, the process of the above event record includes: a) The application calls the e1.record operation of the CLEvent event management interface unit to issue an event control command; b) The Event event management unit of the flow scheduling layer receives the e1.record control command, finds the target event object e1 from the event database unit event_table; adds a time scheduling object SchedEvent to the tail of the scheduling event list e1.sched_events_state[], and the initial state is not ready SCHED_EVENT_NOT_READY; c) The Event event management unit internally generates an event record task for stream s1, recorded as e1.record_task. The e1.record_task includes a pointer to the latest time scheduling object SchedEvent of the target event object e1, recorded as the first time scheduling object pointer e1.record_task.sched_event_ptr, and the pointer points to the last time scheduling object SchedEvent at the tail of the scheduling event list e1.sched_events_state[]; d) At the same time, the event counter e1.record_count is incremented by 1; e) The e1.record_task is placed at the tail of stream s1.

[0066] Taking the event task e1 wait of s2 as described above for illustration, the process of the above event wait includes: a) The application calls the e1.wait operation of the CLEvent event management interface unit to issue an event control command; b) The Event event management unit of the flow scheduling layer receives the e1.wait control command, finds the target event object e1 from the event database unit event_table; c) The Event event management unit internally generates an event wait task for stream s2, recorded as e1.wait_task. The e1.wait_task includes a pointer to the latest time scheduling object SchedEvent of the target event object e1, recorded as the second time scheduling object pointer e1.wait_task.sched_event_ptr, and the pointer points to the last time scheduling object SchedEvent at the tail of the scheduling event list e1.sched_events_state[]; d) The e1.wait_task is placed at the tail of stream s2.

[0067] Through the above two-step processes of event record and event wait, event dependencies are added to the driver task.

[0068] 603. Execute event dependencies to enable the flow task queue to achieve parallel synchronous waiting.

[0069] In the embodiment of the present invention, when the current flow task queue executes the record event of the current driving task, the state of the time scheduling object pointed to by the first time scheduling object pointer is changed to ready to complete; when the state of the time scheduling object pointed to by the second time scheduling object pointer is not ready, the state of the corresponding parallel flow task queue is switched to the waiting event completion state; when the state of the time scheduling object pointed to by the second time scheduling object pointer is ready to complete, the state of the corresponding parallel flow task queue is switched to the executable state; traverse the parallel flow task queue in the waiting event completion state, and check the state of the time scheduling object corresponding to the parallel flow task queue in the waiting event completion state; if the state of the time scheduling object corresponding to the parallel flow task queue in the waiting event completion state is changed to ready to complete, the state of the parallel flow task queue in the waiting event completion state is switched to the executable state. By determining the record event state of the current driving task of the current flow task queue through the first time scheduling object pointer, when the record event state of the current flow task queue is ready to complete, the processing of the waiting events in the parallel flow task queue is started, so that the parallel flow task queue can achieve parallel synchronous waiting according to the completion of the waiting events.

[0070] Specifically, further, the flow scheduling layer schedules the tasks of s1 and s2. Specifically, it is scheduled according to the sequence of the driving task and the event task in the flow task queue. The scheduling of the event task can refer to Figure 3 . Specifically, the wait_task type task is added to the parallel flow task queue. If the time scheduling object SchedEvent corresponding to the waiting event is not ready (the second time scheduling object pointer e1.wait_task.sched_event_ptr indicates SCHED_EVENT_NOT_READY), then the parallel flow task queue enters the waiting event completion state. Traverse the flow task queue in the waiting event completion state, check the waiting event flag. If the second time scheduling object pointer wait_task.sched_event_ptr of the read waiting event is ready to complete SCHED_EVENT_COMPLETE, then switch the state of the flow task queue to the executable state.

[0071] Further, the processing flow of e1.record_task: When the flow task queue schedules and executes the e1.record_task task, it marks the status of the time scheduling object SchedEvent of this task as completed, and at the same time changes the status of the first time scheduling object pointer record_task.sched_event_ptr to ready to complete SCHED_EVENT_COMPLETE.

[0072] Furthermore, the processing flow of e1.wait_task: When the flow task queue schedules and executes the e1.wait_task task, it reads the status of the time scheduling object SchedEvent of this task. If it is not completed, then the flow state machine switches to the waiting event completion state; if it is completed, then it continues to execute the next driving task. Application reset CLEvent event management interface unit: In the event database event_table in the flow scheduling layer, one CLEvent event management interface unit corresponds to multiple time scheduling objects SchedEvent. Each time the application calls the e1.record operation, a new time scheduling object SchedEvent will be added to the end of the scheduling event list e1.sched_events_state[]. The application needs to call the e1.reset operation after e1.wait to clear the scheduling event list e1.sched_events_state[].

[0073] Optionally, when the number of driving tasks that can be added to the current flow task queue reaches a preset value, a marker event object is created, and the application thread is blocked to generate a flow marker task for the current flow task queue. The above flow marker task includes a third time scheduling object pointer, and the above third time scheduling object pointer points to the above marker event object; the above flow marker task is added to the end of the current flow task queue as a flow marker event; when the current flow task queue executes to the above flow marker event, the blocked above application thread is awakened, and the above marker event object is released. Blocking the application thread when the number of driving tasks exceeds the preset value can prevent too many tasks from entering the scheduling and causing the flow task queue to block; when the driving task is processed, the application thread is awakened by pointing the third time scheduling object pointer to the above marker event object to ensure the smoothness of task processing.

[0074] Further, please refer to Figure 8 , Figure 8 which is a schematic diagram of CLStream synchronous waiting provided by an embodiment of the present invention. As Figure 8 shown, after the application issues N tasks under stream s1, it calls s1.sync to synchronously wait for all the previous N tasks to be executed completely.

[0075] Specifically, 1) The application calls the s1.sync operation to wait for stream synchronization, applies for a marker event object sig1 from the CLSignal thread management interface unit, and creates a new stream marker task s1.sync_task. The stream marker task includes a third time scheduling object pointer s1.sync_task.signal_ptr that points to the marker event object sig1, and is sent to the stream scheduling layer for processing. The application thread calls the thread to wait for sig1.wait and enters the blocked state. 2) The task distribution unit of the stream scheduling layer receives the s1.sync_task task and places it at the end of s1. 3) When the stream scheduling unit of the stream scheduling layer executes the s1.sync_task task, it indicates that all tasks of s1 are completed, and executes the indication operation of the third time scheduling object pointer s1.sync_task.signal_ptr.notify. 4) The operating system scheduler wakes up the blocked application thread, exits from the thread waiting for sig1.wait, and releases the marker event object sig1.

[0076] Optionally, the event database includes a list of dependent events, and the list of dependent events includes a list of marker tasks for the dependent events. The target event object can be found from the above event database; an event marker task is generated. The above event marker task includes a fourth time scheduling object pointer and a fifth time scheduling object pointer. The above fourth time scheduling object pointer points to the above marker event object, and the above fifth time scheduling object pointer points to the time scheduling object in the above scheduling event list; when the above scheduling event list is empty or the status of the above time scheduling object is ready to complete, the above fourth time scheduling object pointer is called; when the above scheduling event list is not empty or the status of the above time scheduling object is not ready, the above event marker task is added to the end of the list of marker tasks for the above dependent events; traverse the above list of dependent events, and sequentially read the record event or wait event. When the status of the time scheduling object pointed to by the above fifth time scheduling object pointer is ready to complete, the above fourth time scheduling object pointer is called; the corresponding record event or wait event is deleted from the above list of dependent events, and the above marker event object is released. After waking up the blocked application thread, the corresponding dependent event is deleted from the list of dependent events, and the above marker event object is released, which can release the resources of the list of dependent events to add new dependent events.

[0077] Further, please refer to Figure 9 , Figure 9 which is a schematic diagram of CLEvent synchronization waiting provided by an embodiment of the present invention, as shown in Figure 9As shown, thread 1 sends tasks a1, a2... on stream s1 and performs an e1.sync operation at time t1. Since the scheduling of s1 has not been executed yet, thread 1 is blocked until s1 executes up to e1 at time t3, at which point thread 1 is awakened and continues to work. Thread 2 continues to send tasks a3, a4... on stream s1 and performs an e1.sync operation at time t2, corresponding to waiting for the completion of the previous tasks a1 to a4. Since the scheduling of s1 has not finished executing tasks a1 to a4, thread 2 is blocked. At time t4, s1 executes up to e1 and thread 2 is awakened and continues to work.

[0078] Specifically, after the target event object e1 is created in the CLEvent event management interface unit: 1. The application calls the e1.sync operation to wait for event synchronization: Apply for the marker event object sig1 from the CLSignal thread management interface unit, and create a new event marking task e1.sync_task. The pointer e1.sync_task.signal_ptr of the fourth time scheduling object in the event marking task e1.sync_task points to the event marking object sig1, which is sent to the stream scheduling layer for processing. The application thread calls the thread wait sig1.wait to enter the blocked state. 2. Processing of the e1.sync_task task in the Event event management unit of the stream scheduling layer: 1) Find the target event object e1 in the event database; 2) If the scheduling event list e1.sched_events_state[] is empty or the state of the last time scheduling object SchedEvent at the tail is READY TO COMPLETE SCHED_EVENT_COMPLETE, then call the pointer e1.sync_task.signal_ptr.notify of the fourth time scheduling object to indicate the operation and exit the processing; otherwise, continue to process the remaining tasks; 3) The dependent event list wait_event_task[] in the event database stores the list of marker tasks (sync task list) of dependent events. Add the event marking task e1.sync_task to the tail of the list of marker tasks of dependent events, and record the information of the time scheduling object SchedEvent corresponding to the dependent event. The pointer e1.sync_task.sched_event_ptr of the fifth time scheduling object points to the last time scheduling object SchedEvent in the scheduling event list e1.sched_events_state[]. 3. Stream scheduling extension: Each time the scheduling traverses the dependent event list wait_event_task[] in the event database, reads the dependent events of the tasks in sequence. When the state of the pointer e1.sync_task.sched_event_ptr of the fifth time scheduling object is READY TO COMPLETE SCHED_EVENT_COMPLETE, then call the pointer e1.sync_task.signal_ptr.notify of the fourth time scheduling object to indicate the operation, and delete the completed dependent events from the dependent event list wait_event_task[]. 4. The operating system scheduling wakes up the blocked application thread, exits from the waiting thread sig1.wait, and releases the event marking object sig1.

[0079] In an embodiment of the present invention, a service to be processed is split into a first number of driving tasks and added to a second number of flow task queues; event dependencies are added to the driving tasks, and the event dependencies include parallel synchronization waiting events between different flow task queues; the event dependencies are executed to enable the flow task queues to achieve parallel synchronization waiting. By splitting the service to be processed into multiple driving tasks and then converting the driving tasks into a driving task flow and adding it to multiple flow task queues, the scheduling between multiple threads is converted into the scheduling between flows, and event dependencies are used to achieve the parallel waiting of multiple flow task queues, thereby achieving task synchronization waiting based on flow task queues. Compared with the direct scheduling between multiple threads, the system scheduling overhead is reduced.

[0080] Optionally, for the scheduling in the flow scheduling layer, driving tasks can be obtained from the application layer.

[0081] In an embodiment of the present invention, the above-mentioned driving tasks may be tasks that require parallel computing, and the above-mentioned driving tasks include control tasks and driving request tasks.

[0082] The above-mentioned application layer includes one or more application threads, and the application threads generate corresponding driving tasks through user interaction. The above-mentioned control task is mainly a command for creating and destroying a driving task flow, and the control task is forwarded by the above-mentioned task distribution unit to the flow control management unit for processing. The above-mentioned driving request task is mainly a task for the upper-layer user to request driving processing calculation through the flow scheduling unit. According to the flow task queue where the driving request task is located, the driving task flow is written to the tail of the corresponding flow task queue to obtain a first-in-first-out flow. The above-mentioned driving response task is mainly that after the driving is completed, the driving task completion status auxiliary information passes through the flow scheduling unit, and the flow scheduling unit triggers the processing of the driving request task of the subsequent flow.

[0083] Furthermore, the above-mentioned driving request task includes a driving ID corresponding to the task, the above-mentioned flow scheduling layer includes one or more flow scheduling threads, the above-mentioned driving layer includes multiple driving threads (the driving threads can also be called drivers), and the above-mentioned driving request task is transmitted in the form of flow data between the application thread, the flow scheduling thread, and the driving thread.

[0084] Based on the control task, the driving request task is converted into a driving task flow and added to the flow task queue.

[0085] In an embodiment of the present invention, the above-mentioned control task is processed through the above-mentioned flow scheduling layer. The above-mentioned flow scheduling layer creates and destroys a driving task flow through the above-mentioned control task and converts the above-mentioned driving request task into a driving task flow; the conversion of the above-mentioned driving request task into a driving task flow can be performed by means of forced conversion, so as to convert the data format of the application thread into a flow data format to obtain the above-mentioned driving task flow.

[0086] Further, based on the above control task, when creating a flow task queue, it is determined whether the number of flow task queues to be created exceeds a first quantity threshold; if the number of flow task queues to be created does not exceed the first quantity threshold, a new flow task queue is created; the above drive request task is forcibly converted into a drive task flow according to a preset conversion rule and added to the above new flow task queue according to the first-in, first-out rule.

[0087] Furthermore, based on the above control task, when destroying a flow task queue, it is determined whether there is an unfinished drive task flow in the flow task queue to be destroyed; if there is an unfinished drive request task flow in the flow task queue to be destroyed, and / or if the number of flow task queues to be created exceeds the first quantity threshold, a first failure message is returned to the application layer; based on the above control task, it is determined whether the number of drive task flows in the flow task queue exceeds a second quantity threshold; if the number of drive task flows in the flow task queue exceeds the second quantity threshold, the tasks of the application layer are blocked and a second failure message is returned to the application layer.

[0088] Specifically, when there is an unfinished drive request task flow in the flow task queue to be destroyed, it means that the previous task has not been completed and needs to be continued; the number of flow task queues to be created exceeds the first quantity threshold, which means that the parallel flow task queues in the flow scheduling layer reach the bearing limit.

[0089] The above first failure message includes a creation failure message and a destruction failure message. The creation failure message can be used to prompt the user that the creation of the flow task queue fails, and the destruction failure message can be used to prompt the user that the destruction of the flow task queue fails.

[0090] The above first quantity threshold can be understood as the maximum number of parallel flow task queues. In the embodiment of the present invention, the first quantity threshold is preferably 1024. When creating a flow task queue, it is determined whether the number of flow task queues to be created exceeds 1024; if the number of flow task queues to be created does not exceed 1024, a new flow task queue is created, and if the number of flow task queues to be created exceeds 1024, a creation failure message is returned. When destroying a flow task queue, if it is detected that there is still a drive task flow in the flow task queue, it means that there is an unfinished drive task flow in the flow task queue, and a destruction failure message is returned.

[0091] The above second quantity threshold can be understood as the maximum flow data volume of drive task flows in a flow task queue. If the data volume of drive task flows in the flow task queue exceeds the maximum flow data volume of the flow task queue, the tasks of the application layer are blocked and a second failure message is returned to the application layer.

[0092] Based on the drive response task, drive and distribute the drive task flow in the flow task queue.

[0093] In an embodiment of the present invention, after the drive is completed, the flow scheduling unit can be notified through the drive task completion status auxiliary information, so that the drive request task processing can be triggered after the flow scheduling unit.

[0094] Optionally, the above flow scheduling unit can take out the above drive task flow from the above flow task queue; according to the above drive response task, call the above drive load query function and the application and release functions of the above drive task completion status, and return the drive status of the drive required by the above drive task flow; if the above drive status is available, mark the above drive task flow as entering the waiting drive completion state, and when the returned drive status is executable, switch the above drive task flow to the executable state; if the above drive status is unavailable, mark the above drive task flow as waiting for the drive resource to be available; traverse the drive task flows in the above waiting drive resource available state in real time or in real time, and call the drive load query function to query the load status of the corresponding drive. If the above load status meets the preset executable conditions, switch the corresponding drive task flow in the waiting drive resource available state to the executable state.

[0095] In an embodiment of the present invention, all executable drive task flows can be traversed, and the drive task flow is taken out from the head of the corresponding flow task queue and handed over to the above drive distribution unit for processing. The above drive distribution unit receives the drive task flow of the flow scheduling unit, parses the drive id of the drive request task, searches for the matching drive registration information in the drive storage unit according to the drive id, and calls the drive load query function through the above drive distribution unit to query the load status of the drive corresponding to the drive id.

[0096] If the load of the driver corresponding to the driver ID is high, it indicates that the driver corresponding to the driver ID is in a busy state. Then, the driver status is set to unavailable (failed) and returned to the above-mentioned flow scheduling unit. The above-mentioned flow scheduling unit then marks the driver task flow as waiting for the driver resource to be available. If the load of the driver corresponding to the driver ID is low, it indicates that the driver corresponding to the driver ID is in an available state. Then, the driver status is set to available and returned to the above-mentioned flow scheduling unit. The above-mentioned flow scheduling unit then marks the driver task flow as waiting for the driver to complete, and records the auxiliary information of the driver task completion status that the driver task flow is waiting for (the driver status is executable). If the auxiliary information of the driver task completion status is received, the driver task flow waiting for the auxiliary information of the driver task completion status is found, and the status of the driver task flow is switched to the executable state. Further, all driver task flows waiting for the driver resource to be available can be traversed. According to the driver ID waiting for the resource, the driver load query function is called through the driver distribution unit to query the load status of the driver corresponding to the driver ID. If the queried driver load is low, the status of the driver task flow is switched from waiting for the driver resource to be available to the executable state.

[0097] Match the distributed driver in the driver layer to process the driver task flow.

[0098] In the embodiment of the present invention, the executable driver required to match and execute the driver task flow in the executable state is matched in the driver layer; the above-mentioned driver processing function is called to forward the driver task flow in the executable state to the above-mentioned executable driver for processing.

[0099] Further, the driver threads in the driver layer can be registered through the above-mentioned driver information registration unit and then stored in the above-mentioned driver information storage unit. In the initialization stage, the driver ID, driver load query function, motion message processing function, and application and release functions for the driver task completion status of each driver are obtained; according to the driver ID, driver load query function, driver processing function, and application and release functions for the driver task completion status of the driver, the driver is registered to obtain driver information; the driver information is stored in the driver information table, and the driver information in the driver information table is updated in real time according to the driver load query function, driver processing function, and application and release functions for the driver task completion status.

[0100] Among them, the above application and release functions for the drive task completion status are used to process the above auxiliary information on the drive task completion status. The above drive load query function is used to query the load conditions of each drive thread in the drive layer, and the above drive processing function is used to call the corresponding drive thread in the drive layer to process the drive task flow. The above auxiliary information on the drive task completion status further includes a resource release request. After receiving a drive response task, if the auxiliary information on the drive task completion status corresponding to the drive response task is a resource release request, the drive distribution unit will release the resources for the drive task flow corresponding to the drive response task.

[0101] Specifically, when each drive request task is issued, a corresponding resource for the auxiliary information on the drive task completion status will be allocated. After the drive request task is completed, the flow scheduling unit is notified through the auxiliary information on the drive task completion status. The flow scheduling unit performs scheduling based on the auxiliary information on the drive task completion status and releases the corresponding resource for the auxiliary information on the drive task completion status after completion.

[0102] In the embodiment of the present invention, by converting the drive request task into a drive task flow, the scheduling between multiple threads is converted into the scheduling between flows. The scheduling between drive task flows is realized by using the flow task queue and drive distribution. Since the scheduling is performed through the flow task queue, compared with the direct scheduling between multiple threads, the system scheduling overhead is reduced. In addition, the decoupling between the application layer and the drive layer can be achieved through the flow task queue, and extension can be performed by configuring the flow task queue and the drive.

[0103] Optionally, in a possible embodiment, there may be one above-mentioned flow scheduling thread. It can be understood that the above-mentioned flow scheduling is implemented by an independent thread. Through the above-mentioned independent flow scheduling thread, the above-mentioned application thread and drive thread are decoupled, so that the above-mentioned task synchronization waiting system in the embodiment of the present invention can be extended by configuring the flow task queue and the drive.

[0104] Further, in the case of implementing flow scheduling by an independent thread, a preset number of flow task queues can be scheduled in parallel. For example, 1024 flow task queues are scheduled in parallel. Any internal time-consuming processing will seriously affect the scheduling efficiency. The flow scheduling thread can be prohibited from executing any other computing tasks. The drive layer can be designed as a drive thread, and the general drive processing function (which can also be called the drive task synchronization waiting function) registered in the driver_register_table (drive information storage unit) will forward the drive request task in the flow scheduling to the drive thread for processing.

[0105] In a possible embodiment, the above-mentioned drive request task is passed among the application thread, the stream scheduling thread, and the drive thread. To reduce the storage management overhead of the drive request task, the relevant data structure definition method is as follows: Define a general drive message DrvCommonTask: The general drive message includes information such as driver id and driver event; Define respective drive messages: Define respective drive messages according to the driver id. For example, the DrvTaskA1 message of driver A, the message header DrvTaskA1::header is of the DrvCommonTask type, and the subsequent DrvTaskA1::body stores the specific parameter configuration message of driver A.

[0106] Specifically, taking DrvTaskA1 as an example, the storage of relevant data is described as follows: 1) The upper-layer user creates a DrvTaskA1 object in the application thread and sends it to the stream scheduling thread for processing; 2) After receiving the drive request task, the stream scheduling thread casts it to the general drive message DrvCommonTask for processing; During the processing, the drive request task object is not deleted, but directly forwarded to the driver A thread for processing; 3) After receiving the drive request task, the driver A thread casts it to the DrvTaskA1 type for processing, and releases the drive request task after processing. In this way, the storage management overhead of the drive request task can be reduced.

[0107] In a possible embodiment, the obtained above-mentioned drive task can be retained in a preset task queue; Determine whether the above-mentioned drive task stream corresponding to the above-mentioned drive task is completed; If the above-mentioned drive task stream is completed, release the above-mentioned drive task from the above-mentioned preset task queue; If the above-mentioned drive task stream is not completed, continue to detain the above-mentioned drive task in the above-mentioned preset task queue. In this way, during the processing of the drive task stream, when a problem occurs, the above-mentioned drive task can be reused, and there is no need to search for the corresponding drive task in the application layer.

[0108] It should be noted that the task synchronization waiting method provided by the embodiments of the present invention can be applied to devices such as smartphones, computers, and servers that can perform task synchronization waiting.

[0109] Optionally, please refer to Figure 10 , Figure 10 is a schematic structural diagram of a task synchronization waiting device provided by the embodiments of the present invention. As Figure 10 shown, the device includes:

[0110] A splitting module 1001, configured to split the service to be processed into a first number of drive tasks and add them to a second number of stream task queues, and the second number of stream task queues are in a parallel relationship;

[0111] An adding module 1002 is used to add event dependencies to the drive task, and the event dependencies include parallel synchronization waiting events between different flow task queues;

[0112] An execution module 1003 is used to execute the event dependencies, so that the flow task queues achieve parallel synchronization waiting.

[0113] Optionally, the splitting module 1001 is further configured to determine a second quantity of flow task queues according to the total data volume of the service to be processed; split the service to be processed into a first quantity of drive tasks, and configure the parallel and serial relationships between the drive tasks through the flow task queues; correspondingly add the parallel drive tasks to the parallel flow task queues, and configure the serial drive tasks in the flow task queues.

[0114] Optionally, the event dependencies include dependencies of recording events and dependencies of waiting events, and the adding module 1002 is further configured to create a recording event and a waiting event of the current drive task; add the recording event of the current drive task to the current flow task queue, and add the waiting event of the current drive task to the parallel queue of the current flow task queue, where the current drive task is located in the current flow queue.

[0115] Optionally, the adding module 1002 is further configured to create an event object for the current drive task in a preset event database, where the event object includes an event counter and a scheduling event list, the initial value of the event counter is 0, and the scheduling event list is initially empty; based on the event object, create the recording event and the waiting event of the current drive task.

[0116] Optionally, the adding module 1002 is further configured to find a target event object from the event database; add a time scheduling object to the tail of the scheduling event list in the target event object, and the initial state of the time scheduling object is unprepared; generate an event recording task for the current flow task queue, where the event recording task includes a first time scheduling object pointer, and the first time scheduling object pointer points to the time scheduling object at the tail of the scheduling event list; add the event recording task as a recording event to the tail of the current flow task queue.

[0117] Optionally, the adding module 1002 is further configured to find a target event object from the event database; generate an event waiting task for the parallel flow task queue, where the event waiting task includes a second time scheduling object pointer, and the second time scheduling object pointer points to the time scheduling object at the tail of the scheduling event list; add the event waiting task as a waiting event to the tail of the parallel flow task queue.

[0118] Optionally, the execution module 1003 is further configured to, when the record event of the current driving task is executed in the current stream task queue, change the status of the time scheduling object pointed to by the first time scheduling object pointer to ready to complete; when the status of the time scheduling object pointed to by the second time scheduling object pointer is not ready, switch the status of the corresponding parallel stream task queue to waiting for event completion status; when the status of the time scheduling object pointed to by the second time scheduling object pointer is ready to complete, switch the status of the corresponding parallel stream task queue to executable status; traverse the parallel stream task queue in the waiting for event completion status, and check the status of the time scheduling object corresponding to the parallel stream task queue in the waiting for event completion status; if the status of the time scheduling object corresponding to the parallel stream task queue in the waiting for event completion status is changed to ready to complete, switch the status of the parallel stream task queue in the waiting for event completion status to executable status.

[0119] Optionally, when the number of driving tasks added to the current stream task queue reaches a preset value, the execution module 1003 is further configured to create a marker event object and block the application thread; generate a stream marker task for the current stream task queue, where the stream marker task includes a third time scheduling object pointer, and the third time scheduling object pointer points to the marker event object; add the stream marker task as a stream marker event to the tail of the current stream task queue; when the current stream task queue executes the stream marker event, wake up the blocked application thread and release the marker event object.

[0120] Optionally, the event database includes a dependency event list, and the dependency event list includes a marker task list of dependency events. The dependency events are record events or waiting events. The execution module 1003 is further configured to find a target event object from the event database; generate an event marker task, where the event marker task includes a fourth time scheduling object pointer and a fifth time scheduling object pointer, the fourth time scheduling object pointer points to the marker event object, and the fifth time scheduling object pointer points to the time scheduling object in the scheduling event list; when the scheduling event list is empty or the status of the time scheduling object is ready to complete, call the fourth time scheduling object pointer; when the scheduling event list is not empty or the status of the time scheduling object is not ready, add the event marker task to the tail of the marker task list of the dependency event; traverse the dependency event list, and sequentially read the record event or the waiting event. When the status of the time scheduling object pointed to by the fifth time scheduling object pointer is ready to complete, call the fourth time scheduling object pointer; delete the corresponding record event or waiting event from the dependency event and release the marker event object.

[0121] It should be noted that the task synchronization waiting device provided by the embodiments of the present invention can be applied to devices such as smart phones, computers, and servers that can perform task synchronization waiting.

[0122] The task synchronization waiting device provided by the embodiments of the present invention can implement each process realized by the task synchronization waiting method in the above method embodiments, and can achieve the same beneficial effects. To avoid repetition, it will not be elaborated here.

[0123] See Figure 11 , Figure 11 is a schematic structural diagram of an electronic device provided by the embodiments of the present invention. As Figure 11 shown, it includes: a memory 1102, a processor 1101, and a computer program of the task synchronization waiting method stored on the memory 1102 and executable on the processor 1101, where:

[0124] The processor 1101 is used to call the computer program stored in the memory 1102 and execute the following steps:

[0125] Split the service to be processed into a first number of driving tasks and add them to a second number of flow task queues, and the second number of flow task queues are in a parallel relationship;

[0126] Add event dependencies to the driving tasks, and the event dependencies include parallel synchronization waiting events between different flow task queues;

[0127] Execute the event dependencies to enable the flow task queues to achieve parallel synchronization waiting.

[0128] Optionally, the step of splitting the service to be processed into a first number of driving tasks and adding them to a second number of flow task queues executed by the processor 1101 includes:

[0129] Determine the second number of flow task queues according to the total data volume of the service to be processed;

[0130] Split the service to be processed into a first number of driving tasks, and configure the parallel and serial relationships between the driving tasks through the flow task queues;

[0131] Correspondingly add the parallel driving tasks to the parallel flow task queues, and configure the serial driving tasks in the flow task queues.

[0132] Optionally, the event dependencies include dependencies of record events and dependencies of waiting events. The step of adding event dependencies to the driving tasks executed by the processor 1101 includes:

[0133] Create a record event and a waiting event for the current driving task;

[0134] Add a record event of the current driving task to the current stream task queue, and add a waiting event of the current driving task to the parallel queue of the current stream task queue, where the current driving task is located in the current stream queue.

[0135] Optionally, the creation of the record event and the waiting event of the current driving task executed by the processor 1101 includes:

[0136] Create an event object for the current driving task in a preset event database. The event object includes an event counter and a scheduling event list. The initial value of the event counter is 0, and the scheduling event list is initially empty;

[0137] Based on the event object, create the record event and the waiting event of the current driving task.

[0138] Optionally, the creation of the record event of the current driving task executed by the processor 1101 based on the event object includes:

[0139] Find a target event object from the event database;

[0140] Add a time scheduling object with an initial state of unprepared to the end of the scheduling event list in the target event object;

[0141] Generate an event recording task for the current stream task queue. The event recording task includes a first time scheduling object pointer that points to the time scheduling object at the end of the scheduling event list;

[0142] Add the event recording task as a record event to the end of the current stream task queue.

[0143] Optionally, the creation of the waiting event of the current driving task executed by the processor 1101 based on the event object includes:

[0144] Find a target event object from the event database;

[0145] Generate an event waiting task for the parallel stream task queue. The event waiting task includes a second time scheduling object pointer that points to the time scheduling object at the end of the scheduling event list;

[0146] Add the event waiting task as a waiting event to the end of the parallel stream task queue.

[0147] Optionally, the execution of the event dependency by the processor 1101 to enable the parallel synchronous waiting of the stream task queue includes:

[0148] When the current stream task queue executes the record event of the current driving task, the state of the time scheduling object pointed to by the first time scheduling object pointer is changed to ready to complete;

[0149] When the state of the time scheduling object pointed to by the second time scheduling object pointer is not ready, the state of the corresponding parallel stream task queue is switched to the waiting event completion state;

[0150] When the state of the time scheduling object pointed to by the second time scheduling object pointer is ready to complete, the state of the corresponding parallel stream task queue is switched to the executable state;

[0151] Traverse the parallel stream task queue in the waiting event completion state, and check the state of the time scheduling object corresponding to the parallel stream task queue in the waiting event completion state;

[0152] If the state of the time scheduling object corresponding to the parallel stream task queue in the waiting event completion state is changed to ready to complete, the state of the parallel stream task queue in the waiting event completion state is switched to the executable state.

[0153] Optionally, the execution of the event dependency by the processor 1101 to enable the parallel synchronization waiting of the stream task queue further includes:

[0154] When the number of driving tasks added to the current stream task queue reaches a preset value, a marker event object is created and the application thread is blocked;

[0155] Generate a stream marker task for the current stream task queue, where the stream marker task includes a third time scheduling object pointer that points to the marker event object;

[0156] Add the stream marker task as a stream marker event to the end of the current stream task queue;

[0157] When the current stream task queue executes the stream marker event, the blocked application thread is awakened and the marker event object is released.

[0158] Optionally, the event database includes a dependency event list for recording dependency events. The dependency events are record events or waiting events, and the dependency event list includes a marker task list of dependency events. When the current stream task queue executes the marker task, the processor 1101 wakes up the blocked application thread and releases the marker event object, including:

[0159] Find the target event object from the event database;

[0160] Generate an event marking task, where the event marking task includes a fourth time scheduling object pointer and a fifth time scheduling object pointer. The fourth time scheduling object pointer points to the marked event object, and the fifth time scheduling object pointer points to the time scheduling object in the scheduling event list;

[0161] When the scheduling event list is empty or the status of the time scheduling object is ready to complete, call the fourth time scheduling object pointer;

[0162] When the scheduling event list is not empty or the status of the time scheduling object is not ready, add the event marking task to the end of the marking task list of the dependent event;

[0163] Traverse the dependent event list, sequentially read the recorded event or the waiting event. When the status of the time scheduling object pointed to by the fifth time scheduling object pointer is ready to complete, call the fourth time scheduling object pointer;

[0164] Delete the corresponding recorded event or waiting event from the dependent event and release the marked event object.

[0165] It should be noted that the electronic device provided in the embodiments of the present invention can be applied to devices such as smartphones, computers, and servers that can perform task synchronization and waiting.

[0166] The electronic device provided in the embodiments of the present invention can implement each process implemented by the task synchronization and waiting method in the above method embodiments, and can achieve the same beneficial effects. To avoid repetition, it will not be elaborated here.

[0167] The embodiments of the present invention also provide a computer-readable storage medium. A computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, it implements each process of the task synchronization and waiting method or the application-side task synchronization and waiting method provided in the embodiments of the present invention, and can achieve the same technical effects. To avoid repetition, it will not be elaborated here.

[0168] Those of ordinary skill in the art can understand that all or part of the processes of implementing the methods in the above embodiments can be completed by instructing relevant hardware through a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0169] The above-disclosed are only the preferred embodiments of the present invention. Of course, the scope of the rights of the present invention cannot be limited thereby. Therefore, equivalent changes made according to the claims of the present invention still fall within the scope covered by the present invention.

Claims

1. A task synchronization waiting method, characterized in that, it includes the following steps: Split the business to be processed into a first number of driving tasks and add them to a second number of flow task queues, and the second number of flow task queues are in a parallel relationship; The step of splitting the business to be processed into a first number of driving tasks and adding them to a second number of flow task queues includes: determining the second number of the flow task queues according to the total data volume of the business to be processed; splitting the business to be processed into a first number of driving tasks, and configuring the parallel and serial relationships between the driving tasks through the flow task queues; correspondingly adding the parallel driving tasks to the parallel flow task queues, and configuring the serial driving tasks in the flow task queues; Add event dependencies to the driving tasks, and the event dependencies include parallel synchronization waiting events between different flow task queues; The event dependencies include the dependencies of recording events and the dependencies of waiting events. The step of adding event dependencies to the driving tasks includes: creating a recording event and a waiting event for the current driving task; adding the recording event of the current driving task to the current flow task queue, and adding the waiting event of the current driving task to the parallel queue of the current flow task queue, where the current driving task is located in the current flow task queue; The step of creating a recording event and a waiting event for the current driving task includes: creating an event object for the current driving task in a preset event database, the event object includes an event counter and a scheduling event list, the initial value of the event counter is 0, and the scheduling event list is initially empty; based on the event object, creating the recording event and the waiting event of the current driving task; The step of creating the waiting event of the current driving task based on the event object includes: finding a target event object from the event database; generating an event waiting task for the parallel flow task queue, the event waiting task includes a second time scheduling object pointer, and the second time scheduling object pointer points to the time scheduling object at the tail of the scheduling event list; adding the event waiting task as a waiting event to the tail of the parallel flow task queue; Execute the event dependencies to enable the parallel synchronization waiting of the flow task queues.

2. The method according to claim 1, characterized in that, the step of creating the recording event of the current driving task based on the event object includes: finding a target event object from the event database; adding a time scheduling object to the tail of the scheduling event list in the target event object, and the initial state of the time scheduling object is unprepared; generating an event recording task for the current flow task queue, the event recording task includes a first time scheduling object pointer, and the first time scheduling object pointer points to the time scheduling object at the tail of the scheduling event list; adding the event recording task as a recording event to the tail of the current flow task queue.

3. The method according to claim 2, characterized in that, Performing the event dependency to enable the stream task queue to achieve parallel synchronous waiting includes: When the current stream task queue executes the recorded event of the current driving task, change the state of the time scheduling object pointed to by the first time scheduling object pointer to ready to complete; When the state of the time scheduling object pointed to by the second time scheduling object pointer is not ready, switch the state of the corresponding parallel stream task queue to waiting for event completion; When the state of the time scheduling object pointed to by the second time scheduling object pointer is ready to complete, switch the state of the corresponding parallel stream task queue to executable; Traverse the parallel stream task queue in the waiting for event completion state and check the state of the time scheduling object corresponding to the parallel stream task queue in the waiting for event completion state; If the state of the time scheduling object corresponding to the parallel stream task queue in the waiting for event completion state is changed to ready to complete, switch the state of the parallel stream task queue in the waiting for event completion state to executable.

4. The method according to claim 3, wherein, performing the event dependency to enable the stream task queue to achieve parallel synchronous waiting further includes: When the number of driving tasks added to the current stream task queue reaches a preset value, create a marker event object and block the application thread; Generate a stream marker task for the current stream task queue, the stream marker task includes a third time scheduling object pointer, and the third time scheduling object pointer points to the marker event object; Add the stream marker task as a stream marker event to the end of the current stream task queue; When the current stream task queue executes the stream marker event, wake up the blocked application thread and release the marker event object.

5. The method according to claim 4, wherein, the event database includes a dependency event list, and the dependency event list includes a marker task list of dependency events. The dependency event is a recorded event or a waiting event. When the current stream task queue executes the marker task, wake up the blocked application thread and release the marker event object, including: Find the target event object from the event database; Generate an event marker task, the event marker task includes a fourth time scheduling object pointer and a fifth time scheduling object pointer. The fourth time scheduling object pointer points to the marker event object, and the fifth time scheduling object pointer points to the time scheduling object in the scheduling event list; When the scheduling event list is empty or the state of the time scheduling object is ready to complete, call the fourth time scheduling object pointer; When the scheduling event list is not empty or the state of the time scheduling object is not ready, add the event marker task to the end of the marker task list of the dependency event; Traverse the dependency event list, sequentially read the recorded event or the waiting event. When the state of the time scheduling object pointed to by the fifth time scheduling object pointer is ready to complete, call the fourth time scheduling object pointer; Delete the corresponding record event or wait event from the dependent event, and release the tagged event object.

6. A task synchronization waiting device, characterized in that the device includes: A splitting module, configured to split the service to be processed into a first number of driving tasks and add them to a second number of flow task queues, and the second number of flow task queues are in a parallel relationship; The splitting the service to be processed into a first number of driving tasks and adding them to a second number of flow task queues includes: determining the second number of the flow task queues according to the total data volume of the service to be processed; splitting the service to be processed into a first number of driving tasks, and configuring the parallel and serial relationships between the driving tasks through the flow task queues; correspondingly adding the parallel driving tasks to the parallel flow task queues, and configuring the serial driving tasks in the flow task queues; An adding module, configured to add event dependencies to the driving tasks, and the event dependencies include parallel synchronization waiting events between different flow task queues; The event dependencies include dependencies of record events and dependencies of wait events, and adding event dependencies to the driving tasks includes: creating a record event and a wait event of the current driving task; adding the record event of the current driving task to the current flow task queue, and adding the wait event of the current driving task to the parallel queue of the current flow task queue, where the current driving task is located in the current flow task queue; The creating a record event and a wait event of the current driving task includes: creating an event object for the current driving task in a preset event database, the event object includes an event counter and a scheduling event list, the initial value of the event counter is 0, and the scheduling event list is initially empty; creating the record event and the wait event of the current driving task based on the event object; The creating the wait event of the current driving task based on the event object includes: finding a target event object from the event database; generating an event waiting task for the parallel flow task queue, the event waiting task includes a second time scheduling object pointer, and the second time scheduling object pointer points to the time scheduling object at the tail of the scheduling event list; adding the event waiting task as a wait event to the tail of the parallel flow task queue; An execution module, configured to execute the event dependencies to enable the flow task queues to achieve parallel synchronization waiting.

7. A task synchronization waiting system, characterized in that the system includes: an application layer, a flow scheduling layer, and a driving layer, where the application layer is configured to generate driving tasks and receive driving task results, the driving layer is configured to provide driving to calculate the driving tasks, and the flow scheduling layer is configured to implement the steps in the task synchronization waiting method according to any one of claims 1 to 5.

8. An electronic device, characterized in that it includes: A memory, a processor, and a computer program stored on the memory and executable on the processor, wherein when the processor executes the computer program, the steps in the task synchronization waiting method according to any one of claims 1 to 5 are implemented.

9. A computer-readable storage medium, characterized in that a computer program is stored on the computer-readable storage medium, and when the computer program is executed by a processor, the steps in the task synchronization waiting method according to any one of claims 1 to 5 are implemented.

Images