Task processing method, apparatus, device, and storage medium

Abstract

The application provides a task processing method and device, equipment and storage medium, relates to the computer technical field, can be applied to cloud technology, artificial intelligence, intelligent transportation, auxiliary driving and various scenes, the method comprises the following steps: in response to a task processing request, obtaining a queue container corresponding to a to-be-processed task, the queue container holds a serial task queue; in the case where a target element exists in the serial task queue, creating a task group corresponding to the target element based on a plurality of previous elements dependent on the target element; creating a task semaphore corresponding to the task group, the count value of the task semaphore representing the task completion amount of each previous subtask corresponding to the plurality of previous elements, and the maximum count value of the task semaphore corresponding to the number of previous elements of the task group; in response to the count value reaching the maximum count value, triggering scheduling execution of a target subtask to obtain a target execution result. The application can avoid multi-thread task calling errors and improve task processing efficiency.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a task processing method, apparatus, device, and storage medium. Background Technology

[0002] As applications iterate on their features, their core functionalities also need continuous updates and improvements, such as updating or adding the application's Software Development Kit (SDK). After updating features, demo files are typically used to guide users in the proper use of new plugins. However, in complex multi-threaded business scenarios, if the preconditions for function calls are not prepared, or if changes in task execution dependencies are not adapted—such as omitting preconditions for adding a new SDK or revising task dependencies for updating the SDK—call errors can occur.

[0003] For example, in multi-threaded business scenarios, three SDKs are needed: network infrastructure components, push notifications, and splash screen ads. Before using the push notification and splash screen SDKs, a globally unique identifier (GUID) for the device must be obtained from the network infrastructure components. The push notification and splash screen SDKs then request the corresponding functional SDK services after obtaining the GUID. Before feature iteration, the GUID was obtained immediately upon program startup, and other SDKs were initialized based on the GUID. However, with feature iteration, user identification (UID) needs to be added to identify different accounts under the same device. Therefore, two requests need to be initiated after program startup to obtain both the GUID and UID. The push notification and splash screen SDKs also need to be modified to obtain both the GUID and UID simultaneously before performing business processing. At this point, if the push notification and splash screen ad SDK settings are not changed, the initialization of the splash screen and push notification SDKs will fail due to the lack of a certain ID field, ultimately affecting business functionality.

[0004] Therefore, an improved task processing method is needed to avoid the above-mentioned call error. Summary of the Invention

[0005] This application provides a task processing method, apparatus, device, and storage medium that can significantly improve the timeliness and reliability of task processing.

[0006] On the one hand, this application provides a task processing method, the method comprising: In response to a task processing request, a queue container corresponding to the task to be processed is obtained. The queue container holds a serial task queue. The elements in the serial task queue correspond to one of the multiple subtasks of the task to be processed. The order of the elements in the serial task queue corresponds to the task execution order of the multiple subtasks. If a target element exists in the serial task queue, a task group corresponding to the target element is created based on multiple preceding elements that the target element depends on. The execution of the target subtask corresponding to the target element depends on the function execution of the preceding subtask corresponding to the preceding element. Create a task semaphore corresponding to the task group. The count value of the task semaphore represents the task completion amount of each preceding subtask corresponding to the plurality of preceding elements. The maximum count value of the task semaphore corresponds to the number of preceding elements of the task group. In response to the count value reaching the maximum count value, the scheduling and execution of the target subtask are triggered to obtain the target execution result.

[0007] On the other hand, a task processing apparatus is provided, the apparatus comprising: Acquisition module: In response to a task processing request, acquires a queue container corresponding to the task to be processed. The queue container holds a serial task queue. The elements in the serial task queue correspond to one of the multiple subtasks of the task to be processed. The order of the elements in the serial task queue corresponds to the task execution order of the multiple subtasks. First creation module: When a target element exists in the serial task queue, it creates a task group corresponding to the target element based on multiple preceding elements that the target element depends on, wherein the execution of the target subtask corresponding to the target element depends on the function execution of the preceding subtask corresponding to the preceding element. The second creation module is used to create a task semaphore corresponding to the task group. The count value of the task semaphore represents the task completion amount of each preceding subtask corresponding to the plurality of preceding elements. The maximum count value of the task semaphore corresponds to the number of preceding elements of the task group. Triggering module: In response to the count value reaching the maximum count value, trigger the scheduling and execution of the target subtask to obtain the target execution result.

[0008] On the other hand, a computer device is provided, the device including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the task processing method as described above.

[0009] On the other hand, a computer-readable storage medium is provided, wherein at least one instruction or at least one program is stored therein, the at least one instruction or the at least one program being loaded and executed by a processor to implement the task processing method as described above.

[0010] On the other hand, a server is provided, the server including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the task processing method as described above.

[0011] On the other hand, a terminal is provided, the terminal including a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the task processing method as described above.

[0012] On the other hand, a computer program product or computer program is provided, which includes computer instructions that, when executed by a processor, implement the task processing method as described above.

[0013] The task processing method, apparatus, device, storage medium, server, terminal, computer program, and computer program product provided in this application have the following technical effects: In response to a task processing request, this application obtains a queue container corresponding to the task to be processed. The queue container holds a serial task queue, where each element corresponds to a subtask among multiple subtasks of the task to be processed. The order of the elements in the serial task queue corresponds to the execution order of the multiple subtasks. This allows for the management of tasks through the queue container and the serial task queue, facilitating unified task detection in multi-threaded task scenarios. Then, if a target element exists in the serial task queue, a task group corresponding to the target element is created based on its multiple preceding elements. A task semaphore corresponding to the task group is also created. The count value of the task semaphore represents the completion amount of each preceding subtask corresponding to the multiple preceding elements, and the maximum count value of the task semaphore corresponds to the number of preceding elements in the task group. Upon reaching the maximum count value, the scheduling and execution of the target subtask are triggered, yielding the target execution result. Thus, by using queues and semaphores to block and synchronize thread tasks, adaptive configuration for multi-threaded task updates is achieved, avoiding call errors caused by SDK feature iterations such as additions or updates. Simultaneously, resources are fully utilized, reducing the resource overhead of task execution. Attached Figure Description

[0014] To more clearly illustrate the technical solutions and advantages in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application; Figure 2 This is a flowchart illustrating a task processing method provided in an embodiment of this application; Figure 3 This is a schematic diagram of the task processing timing in existing technologies; Figure 4 This is a flowchart illustrating another task processing method provided in an embodiment of this application; Figure 5 This is a framework diagram of a scheduling center provided in an embodiment of this application; Figure 6 This is a flowchart illustrating another task processing method provided in an embodiment of this application; Figure 7 This is a schematic diagram of a task processing timing provided in an embodiment of this application; Figure 8 This is a flowchart illustrating another task processing method provided in an embodiment of this application; Figure 9 This is a flowchart illustrating another task processing method provided in an embodiment of this application; Figure 10 This is a flowchart illustrating another task processing method provided in an embodiment of this application; Figure 11 This is a schematic diagram illustrating the principle of task processing provided in an embodiment of this application; Figure 12 This is a schematic diagram of the framework of a task processing device provided in an embodiment of this application; Figure 13 This is a hardware structure block diagram of an electronic device for a task processing method provided in an embodiment of this application. Detailed Implementation

[0016] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0017] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or server that comprises a series of steps or sub-modules is not necessarily limited to those steps or sub-modules explicitly listed, but may include other steps or sub-modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0018] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0019] Message Queue (MQ): A "first-in, first-out" data structure, typically used to solve problems such as application decoupling, asynchronous messaging, and traffic shaping.

[0020] Serial task queue: A special linear list structure that only allows deletion operations at the front (front) and insertion operations at the rear (rear) of the list. A serial task queue means that tasks in the linear list can only be executed one after another.

[0021] Multithreading: The principle is to divide a processor into several short time slices, and each time slice takes turns executing and processing various applications.

[0022] Time slice: This is a microscopic segment of CPU time allocated to each running process by a time-sharing operating system (in a preemptive kernel, it is the time from the start of a process's execution until it is preempted).

[0023] A Software Development Kit (SDK) is generally a collection of development tools used by software engineers to create application software for specific software packages, frameworks, hardware platforms, and operating systems. Typically, an SDK is used to develop applications for the Windows platform. It facilitates application creation through compilers, debuggers, and software frameworks. It can be as simple as some documentation providing an Application Programming Interface (API) for a programming language, but may also include complex hardware capable of communicating with embedded systems. Common tools include utilities for debugging and other purposes. SDKs often also include sample code, supporting technical annotations, or other supporting documentation to clarify ambiguities for basic reference materials.

[0024] Please see Figure 1 , Figure 1 This is a schematic diagram of an application environment provided in an embodiment of this application, such as... Figure 1 As shown, the application environment may include at least terminal 01 and server 02. In practical applications, terminal 01 and server 02 can be directly or indirectly connected via wired or wireless communication, and this application does not impose any restrictions on this.

[0025] In this application embodiment, server 02 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.

[0026] Specifically, cloud technology refers to a hosting technology that unifies hardware, software, and network resources within a wide area network (WAN) or local area network (LAN) to achieve data computation, storage, processing, and sharing. Cloud technology can be applied to various fields, such as medical cloud, cloud IoT, cloud security, cloud education, cloud conferencing, AI cloud services, cloud applications, cloud calling, and cloud social networking. Based on the cloud computing business model, cloud technology distributes computing tasks across a resource pool composed of numerous computers, enabling various application systems to obtain computing power, storage space, and information services as needed. The network providing these resources is called the "cloud." From the user's perspective, the resources in the "cloud" are infinitely scalable, readily available, on-demand, expandable, and pay-as-you-go. As a provider of basic cloud computing capabilities, a cloud resource pool (referred to as a cloud platform, generally called IaaS (Infrastructure as a Service)) platform is established, deploying various types of virtual resources within the pool for external customers to choose from. The cloud resource pool mainly includes: computing devices (virtualized machines containing operating systems), storage devices, and network devices.

[0027] Based on logical function, a PaaS (Platform as a Service) layer can be deployed on top of the IaaS layer, and a SaaS (Software as a Service) layer can be deployed on top of the PaaS layer. Alternatively, SaaS can be deployed directly on top of IaaS. PaaS is a platform for running software, such as databases and web containers. SaaS refers to various types of business software, such as web portals and bulk SMS senders. Generally speaking, SaaS and PaaS are upper layers compared to IaaS.

[0028] Specifically, the server 02 mentioned above may include physical devices, such as network communication submodules, processors, and memory, and may also include software running on the physical devices, such as applications.

[0029] Specifically, terminal 01 may include physical devices such as smartphones, desktop computers, tablets, laptops, digital assistants, augmented reality (AR) / virtual reality (VR) devices, smart voice interaction devices, smart home appliances, smart wearable devices, and in-vehicle terminal devices, and may also include software running on the physical devices, such as applications.

[0030] In this embodiment, terminal 01 can receive trigger operations for tasks to be processed from server 02 to generate corresponding task processing requests, thereby triggering the task processing flow and providing task processing services. Specifically, it can obtain the queue container corresponding to the task to be processed, check whether the target element exists in the serial task queue held by the queue container, and then create a task group and corresponding task semaphores to detect subtask execution and synchronization, thereby realizing the scheduling and execution of the target subtask. Server 02 can be used for function calls in task scheduling and execution, providing corresponding data.

[0031] Furthermore, it is understandable that Figure 1 The example shown is merely an application environment for one task processing method. This application environment may include more or fewer nodes, and this application does not impose any restrictions on it.

[0032] The application environment involved in this application embodiment, or the terminal 01 and server 02 in the application environment, can be a distributed system formed by connecting clients and multiple nodes (any form of computing device accessing the network, such as servers and user terminals) through network communication. The distributed system can be a blockchain system, which can provide the aforementioned task processing services and data storage services.

[0033] In application scenarios, as application functionality iterates, SDK providers also need to continuously improve basic functions. When the SDK's call order or due to multithreading, network issues, or other reasons causes errors in certain functions, it can affect business operations. Below are two examples of function errors: I. When an SDK executes a relatively independent function, it may use multithreading to retrieve data. For example, the pop-up of the secure keyboard SDK requires the following steps: 1. The client requests authorization from its own server to obtain the authorization result; 2. The client uses the authorization result to request encrypted keyboard data from the secure keyboard server; 3. The client parses the encrypted keyboard data and generates the keyboard page. If step 1 takes three seconds to obtain the authentication result, and if the access party's logic starts step 2 two seconds after the trigger, the authorization result has not yet been returned, leading to the secure keyboard component failing to load. II. In the image push service, the push component is integrated first, followed by the album component. However, due to an internal application logic error, the initialization code for the album component is called before the push component (the album component needs to be initialized after the push component), resulting in the inability to retrieve the pushed images.

[0034] For example, please refer to Figure 3 When performing a task, tasks A and B are started simultaneously before time T0. When task C is executed at time T0, it needs to use data A and B generated by tasks A and B. Since task B does not generate data B until after time T0, task C will report an error.

[0035] The following describes a task processing method based on the aforementioned application environment and scenario. This method is applied to a terminal, and its embodiments can be applied to various scenarios, including but not limited to cloud technology, artificial intelligence, smart transportation, and assisted driving. Please refer to... Figure 2 , Figure 2 This is a flowchart illustrating a task processing method provided in an embodiment of this application. This specification provides method operation steps as shown in the embodiments or flowcharts, but based on conventional or non-inventive labor, more or fewer operation steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual system or server product execution, the method can be executed sequentially according to the embodiments or drawings, or in parallel (e.g., in a parallel processor or multi-threaded processing environment). Specifically, as... Figure 2 As shown, the method may include the following steps S201-S207.

[0036] S201: In response to a task processing request, obtain the queue container corresponding to the task to be processed. The queue container holds a serial task queue.

[0037] Specifically, the task processing request can be generated based on the task trigger operation received by the terminal for the task to be processed. For example, in response to the submission operation of the card recognition control, a task processing request corresponding to the card recognition task is generated. The task to be processed includes multiple sub-tasks. It can be understood that the task to be processed can include multiple execution steps, and each execution step includes at least one program execution (mainly including function calls). For example, when the SDK executes the card recognition task, it needs to go through three steps: acquiring the card image from the camera / album, extracting the required information through the image recognition algorithm, and outputting the required information to the display interface to realize the result display. Among them, acquiring the card image can be further broken down into three program executions: acquiring camera / album permissions, opening peripherals, and starting image input. The program execution involved in the above steps are the preconditions that need to be determined before the SDK executes the card recognition task. Each function call is defined as a sub-task of the task to be processed. Accordingly, in response to a task processing request, after obtaining the task information of the task to be processed, which includes the execution of each program within the task, primarily the function calls of each program, the task information is added to the serial task queue for subsequent task scheduling. The serial task queue is held by a queue container, and each queue container can maintain one serial task queue. One task to be processed can correspond to one or more queue containers.

[0038] Specifically, each element in the serial task queue corresponds to one of the multiple subtasks of the task to be processed, and the order of the elements in the serial task queue corresponds to the execution order of the multiple subtasks. It should be noted that the elements can store function call information for the corresponding subtask, such as the `call` function. The serial task queue can also store subtasks in the task to be processed that have dependencies; that is, if a subtask must use the function of a preceding subtask to execute, then there is a dependency between that subtask and the preceding subtasks. The order of the elements in the serial task queue is the same as the execution order of the corresponding subtasks within it.

[0039] In practical applications, please refer to Figure 4 S201 can specifically include S2011-S2013: S2011: In response to a task processing request, obtain the task invocation information of the task to be processed.

[0040] Specifically, the task invocation information includes the task execution order and task dependencies of multiple subtasks.

[0041] S2012: Create a queue container corresponding to the task to be processed. The queue container holds the initial serial queue. S2013: Based on the task execution order and task dependencies, add subtasks with task dependencies from multiple subtasks to the initial serial queue in sequence to obtain the serial task queue.

[0042] Specifically, in response to a task processing request, a queue container is created, associated with the task to be processed, the task is parsed, and its subtasks are identified (specifically, the function calls within the task). Subtasks with dependencies are selected based on task dependencies, and added to an initial serial queue according to their execution order. In the resulting serial task queue, dependencies between elements are marked based on task dependencies. In this way, the task to be processed is broken down into multiple subtasks at the function call granularity, added to the serial queue based on execution order, and their dependencies are marked, facilitating automatic task scheduling, synchronization, and call detection, thus achieving effective management of multi-threaded tasks.

[0043] In some embodiments, the subtasks of the task to be processed also include subtasks without task dependencies, that is, subtasks that do not depend on the function execution of previous subtasks, and / or subsequent tasks do not need to use the function execution of this subtask within a certain time range. In this case, an initial concurrent queue can also be created in the queue container, that is, the queue container also holds the initial concurrent queue. Accordingly, the method also includes: adding subtasks without task dependencies from multiple subtasks to the initial concurrent queue based on task dependencies, to obtain a concurrent task queue. Specifically, the addition and scheduling of tasks in the concurrent task queue can be based on the task execution order. It is understood that the parameters used in function calls may undergo time-consuming operations, such as the time-consuming process of calculating image contours and binarization in card recognition. By setting up serial task queues and concurrent task queues, tasks in each queue can be processed separately based on different threads, improving task processing efficiency and reducing task blocking.

[0044] For example, subtasks can be categorized based on task dependencies. Subtasks with task dependencies are marked as MustWait, meaning that subsequent tasks must use the functions executed in the preceding function. For instance, in card recognition, after selecting and reading an image from the album and generating an image object, all subsequent operations are performed on this image object. Therefore, subtasks that require the image object after its generation can be marked as MustWait. Subtasks without task dependencies are marked as OptionalWait, meaning that within a certain time frame, subsequent subtasks can use functions that do not require the execution of this subtask. For example, in card recognition, the subtask of turning on the flashlight is only needed in low-light conditions. Subtasks marked as MustWait are added to the serial task queue, and subtasks marked as OptionalWait are added to the concurrent task queue.

[0045] For details, please refer to Figure 5It can create a scheduling center, such as a scheduling center plugin built into the SDK. When the task to be processed is a long-running task or a multi-threaded task including asynchronous tasks, the scheduling center is started. The scheduling center creates and maintains the queue container corresponding to the task processing request, and performs subtask scheduling.

[0046] S203: If a target element exists in the serial task queue, create a task group corresponding to the target element based on the multiple preceding elements that the target element depends on.

[0047] Specifically, the execution of the target subtask corresponding to the target element depends on the function execution of the preceding subtask corresponding to the preceding element; that is, the execution of the target subtask requires the function execution of multiple preceding subtasks. In practical applications, before S203, there is also a step to determine the target element, specifically including S301-S303: S301: Read the elements in the serial task queue sequentially; S303: When the subtask corresponding to the current element depends on multiple preceding subtasks, the current element is determined as the target element, and the elements corresponding to the multiple preceding subtasks are determined as preceding elements.

[0048] Specifically, "relying on multiple preceding subtasks" means that the execution of a function requires the execution of multiple preceding subtasks. Step S205 can be executed if the first target element in the serial task queue has been read, or it can be executed after iterating through and reading each element in the serial task queue, determining all target elements, and then targeting the first target element in the execution order.

[0049] S205: Create the task semaphore corresponding to the task group.

[0050] Specifically, the count value of the task semaphore represents the task completion amount of each preceding subtask corresponding to multiple preceding elements. The maximum count value of the task semaphore corresponds to the number of preceding elements in the task group. The task semaphore can ensure that two or more preceding subtasks are not called concurrently. In this way, by using the task semaphore to block the target subtask and synchronize thread tasks, the CPU multi-core resources can be fully utilized.

[0051] Specifically, the number of preceding elements is the number of preceding subtasks corresponding to the task group. When the task group corresponds to one task semaphore, the maximum count value of the task semaphore is the same as the number of preceding elements of the task group.

[0052] S207: In response to the count value reaching the maximum count value, the scheduling and execution of the target subtask is triggered, and the target execution result is obtained.

[0053] Specifically, the task execution result may include the result data of the target subtask, as well as intermediate variables and intermediate data obtained during the execution process.

[0054] In this embodiment, reaching the maximum count value indicates that all preceding subtasks associated with the target subtask in the task group have been scheduled for execution, or have all been successfully executed, thus no longer blocking the target subtask and triggering its scheduling execution. If the count value reaches the maximum count value, it indicates that there are unscheduled subtasks or unfinished subtasks among the preceding subtasks in the task group, and the task executing the target subtask is blocked. Specifically, after the target execution result is completed, the task group is destroyed. In the queue container corresponding to the pending task, after each subtask is executed, the execution result of the pending task is obtained. Optionally, the execution results of the subtasks can be merged to obtain the final execution result.

[0055] In summary, the above technical solutions enable the management of tasks to be processed through queue containers and serial task queues. In multi-threaded task scenarios, they facilitate unified task detection and the blocking and synchronization of thread tasks through queues and semaphores. By leveraging multi-threading principles, asynchronous tasks with single time slices can be processed by using semaphores to wait for updates, achieving adaptive configuration for multi-threaded task updates. This avoids call errors caused by iterative updates or additions to the SDK, while also making full use of resources and reducing the resource overhead of task execution.

[0056] In some embodiments, the initial count value of the task semaphore after its creation is 0, and the count value of the task semaphore is updated as preceding subtasks in the task group are scheduled and executed. Accordingly, in practical applications, before S207, please refer to... Figure 6 The method may also include S401-S403: S401: Schedule and execute each preceding subtask corresponding to the task group; S403: In response to feedback that the preceding subtask has completed execution, update the count value of the task semaphore until the count value reaches the maximum count value.

[0057] Specifically, after creating a task group, each preceding subtask within the task group can be concurrently scheduled for execution. After any preceding subtask completes, the count of the task semaphore is incremented by 1, and so on, until all preceding subtasks have completed, at which point the task semaphore count reaches its maximum value. Thus, after creating a task group, the task semaphore counts the execution status and progress of each preceding subtask that the target subtask depends on, achieving automatic task detection and synchronization without the need to maintain a detection thread. This reduces the error rate and memory overhead during task execution. Furthermore, when the serial task queue includes multiple branches, multiple task groups can be created in parallel, enabling concurrent execution of multiple task groups and further improving resource utilization and task processing efficiency.

[0058] For example, please refer to Figure 7 The task group corresponds to three preceding subtasks, A, B, and C, with a maximum count value of 3. At time T0, asynchronous subtask B completes execution, and the task semaphore is 1. At time T1, asynchronous subtask A completes execution, and the task semaphore is 2. At time T2, asynchronous subtask C completes execution, and the task semaphore is 3, reaching the maximum count value and triggering the call of the target subtask.

[0059] In practical applications, task semaphores can be reused; please refer to the relevant documentation. Figure 8 Following S207, the method may also include S501-S505: S501: Initialize the count value of the task semaphore to obtain the empty task semaphore; S503: In response to the creation of the next task group, associate the next task group with the null task semaphore; S505: Set the maximum count value of the empty task semaphore based on the number of preceding elements in the next task group, and generate the task semaphore corresponding to the next task group.

[0060] Specifically, in response to a call to a target subtask, the task semaphore of the task group is initialized by clearing it to obtain an empty task semaphore, and its count value is restored to the initial count value of 0. When a new task group is created, the empty task semaphore is referenced in that new task group. If the new task group corresponds to one target subtask (i.e., one task semaphore), its maximum count value is set to the number of preceding elements in the new task group, i.e., the number of preceding subtasks. This achieves the reuse of the same task semaphore, saving memory overhead and semaphore maintenance costs while fully utilizing resources.

[0061] Correspondingly, before creating a task semaphore for a task group, an empty task semaphore can be searched for. If found, the empty task semaphore is associated with the task group, and its maximum count value is set; if not found, the creation of the task semaphore is triggered.

[0062] As mentioned above, a task group can correspond to one target subtask and be associated with one task semaphore. In some cases, a task group can also correspond to more than one dependent target subtask, such as target subtask D and target subtask E, where the execution of target subtask E depends on the function execution of target subtask D. Accordingly, the number of task semaphores associated with the task group is based on the number of target subtasks corresponding to the task group; for example, if there are two target subtasks, two task semaphores are created. Specifically, each task semaphore is associated with a target subtask and there is a one-to-one correspondence. The maximum count value of each task semaphore is the number of preceding subtasks that its associated target subtask depends on. For example, target subtask D corresponds to task semaphore 1, and target subtask E corresponds to task semaphore 2. The preceding subtasks corresponding to target subtask D in the task group are scheduled for execution, and task semaphore 1 is updated. When task semaphore 1 reaches its maximum count value, that is, when the preceding subtasks corresponding to target subtask D have completed execution, the execution of target subtask D is triggered. Similarly, in response to the successful execution of target subtask D, the scheduling and execution of the preceding subtasks corresponding to target subtask E are triggered, and task semaphore 2 is updated. When task semaphore 2 reaches its maximum count value, that is, when the preceding subtasks corresponding to target subtask E have completed execution, the scheduling and execution of target subtask E is triggered. Thus, by creating task groups corresponding to multiple dependent target subtasks and using multiple semaphores to schedule each target subtask, the creation, destruction, and semaphore clearing of task groups can be saved, thereby reducing task overhead and improving task processing efficiency.

[0063] Based on the foregoing, when the queue container also holds a concurrent task queue, the method further includes: S601: Perform concurrent scheduling and execution of subtasks corresponding to the concurrent task queue; S603: Detect the scheduling and execution time of subtasks corresponding to the concurrent task queue; S605: If the scheduled execution time exceeds the preset time, in response to the execution error of the subsequent subtask, the task execution information of the subtask that exceeded the preset time is written to the task log of the pending task.

[0064] Specifically, the preset duration indicates the upper limit of the scheduling execution time for a subtask in the concurrent task queue. The task execution information can be the execution data and results obtained within the preset duration. A corresponding preset duration T can be set for each subtask in the concurrent task queue. If the scheduling execution time exceeds T, and subsequent subtasks of that subtask encounter errors, the results of the execution within T are output to the task log. If no errors occur, no action is taken. Thus, recording error events based on preset durations effectively records the results of subsequent error location and tracing, facilitating problem handling.

[0065] Based on some or all of the above implementation methods, in this embodiment, the calling objects of each subtask can be encapsulated to unify the format and type of the calling objects. Accordingly, please refer to... Figure 9 The method may also include S701-S703.

[0066] S701: Get the call object of the subtask corresponding to the serial task queue.

[0067] Specifically, the calling object of a subtask can be the object that initiates the function call to the subtask. For example, in a page data loading task, specifically for an image loading subtask, the functional module that initiates the image loading subtask within the corresponding page's functional modules is the calling object. The calling object can include the class name of the caller's class, the caller's identifier, or parameters passed by the caller (such as interface parameters).

[0068] S703: Encapsulates the calling object into a wrapper object of a preset type.

[0069] Specifically, the call objects corresponding to elements in the serial task queue are encapsulated based on preset types. For example, the call object of a subtask marked as MustWait is encapsulated as a MW object. If the call object (such as parameters) for calling an interface of a functional type in the SDK originates from the caller, it is input into the queue container by the caller. The queue container uses the runtime call stack to convert the call object, such as parameters, into specific attributes that the MW object can process and recognize. For example, the parameters are serialized and converted into a specific numeric type. In this way, the call objects are uniformly encapsulated, reducing the difficulty and obstacles of data transmission within the queue and improving data transmission efficiency. For example, uniformly encapsulating the call objects of multi-threaded tasks in the SDK makes the SDK more lightweight to use.

[0070] In practical applications, the lifecycle of the encapsulated object can also be managed based on a preset protocol method. Correspondingly, after S703, the method also includes: in response to the scheduling trigger of the subtask, setting the lifecycle of the encapsulated object, whereby the lifecycle represents the upper limit of the duration for which the calling object corresponding to the encapsulated object is locked. Specifically, before scheduling a subtask, the lifecycle of the encapsulated object is set based on a preset protocol method. In response to the scheduling of the subtask, the calling object is locked, ensuring that it only schedules and executes the current subtask. If the subtask completes within its lifecycle, the calling object is released; if the subtask does not complete within its lifecycle, the calling object is released and a task execution error is reported. In this way, locking the calling object through its lifecycle avoids concurrent task scheduling for the same calling object, reducing the task error rate.

[0071] In some embodiments, the function call information in each element of the serial task queue is further encapsulated to obtain an encapsulated function call object, such as an MW call object. The encapsulation method here can be similar to S703, based on the same preset type. In this way, the attribute of element information is unified, improving data transmission efficiency and task scheduling efficiency.

[0072] S705: Create a reference relationship between the encapsulated object and the task execution result of the subtask.

[0073] Specifically, data transfer between subtasks in the queue can be achieved based on this reference relationship. Please refer to the relevant documentation. Figure 10 S207 can specifically include S2071-S2073: S2071: Based on the reference relationship of the encapsulated objects of each preceding subtask, obtain the execution results of each preceding subtask. S2072: Create a target reference relationship between the encapsulation object of the target subtask and the result of the preceding execution; S2073: Based on the target reference relationship, the target subtasks are scheduled and executed using the results of each preceding execution as input, and the target execution result is obtained.

[0074] Specifically, after the execution of the preceding subtasks that the target subtask depends on is completed, the execution result of the preceding subtask is retrieved based on the reference relationship of its encapsulated object. The encapsulated object of the target subtask is then referenced to the execution result of the preceding subtask, realizing the data transfer of the execution result of the preceding subtask. The target subtask is then executed based on this execution result, and the reference between the encapsulated object of the preceding subtask and the execution result of the preceding subtask is removed. In this way, data transfer is achieved based on the encapsulated object during task execution, bridging the task results and reducing the maintenance cost of task execution.

[0075] In some embodiments, the method further includes creating empty wrapper objects at the head and / or tail of an initial serial queue, the empty wrapper objects being used for data transmission in the serial task queue.

[0076] Specifically, in response to the triggering of pending tasks, the input required by the application's functional modules may originate from external modules. For example, the parameters required by the current SDK's interface may come from external calls to other SDKs. For instance, an SDK displaying images may rely on image data from a downloaded SDK. By creating empty encapsulation objects at the head and / or tail of the serial queue, external input data can be received through the empty encapsulation object at the head of the queue, or data can be output through the empty encapsulation object at the tail of the queue. The caller then assembles and decomposes the data encapsulation objects output by the queue based on a preset protocol method, using this data as input to another serial task queue or SDK. This step is specifically executed by the scheduling center. In this way, the attributes of input and output data between different SDKs or serial queues are unified, bridging the communication mechanisms between different SDKs. There is no need to set up bridging programs between SDKs, nor is it necessary to convert the data type of the first SDK's output parameters to the data type of the second SDK's received parameters, reducing development costs and improving the fault tolerance of task execution.

[0077] In SDK applications, task processing requests and processes trigger SDK interface calls. In response to these calls, the scheduling center obtains the API call to retrieve the task to be processed. It then determines whether the caller is within the SDK. If so, the scheduling center creates a queue container holding an initial serial queue and an initial concurrent queue. The scheduling center splits the task to be processed into multiple subtasks and adds each subtask to the initial serial queue and the initial concurrent queue using the aforementioned methods, resulting in a serial task queue and a concurrent task queue. If the caller originates from outside the SDK, such as another SDK, an empty wrapper object is created and stored at the head of the initial serial queue, thus initiating the subsequent parameter injection and subtask addition process.

[0078] Please refer to Figure 11 External inputs a and b are encapsulated into input encapsulation objects a and b based on empty encapsulation objects, and injected into the serial task queue. The scheduling center and queue container control the parsing of the input encapsulation data in the serial task queue, the scheduling and execution of tasks, and the generation of task execution results. In addition, the data output from the serial task queue is assembled into data encapsulation objects to obtain the input results.

[0079] Understandably, each module (such as the SDK) transmits and bridges data through encapsulated objects when receiving data, outputting data, and making function calls. That is, it uses predefined encapsulated objects to manage the SDK's input, output function calls, and parameter assembly, which can unify the data format of data transmission and the dependencies on communication with the SDK, thereby improving the overall fault tolerance and execution efficiency of task processing.

[0080] In summary, the above technical solutions enable the management of tasks to be processed through queue containers and serial task queues. In multi-threaded task scenarios, they facilitate unified task detection and the use of queues and semaphores to block and synchronize thread tasks, achieving adaptive configuration for multi-threaded task updates. This solves the problem of SDK task management in multi-threaded environments, avoids calling errors caused by SDK feature iterations such as adding or updating, and reduces SDK errors caused by access party calling errors. At the same time, it can make full use of resources and reduce the resource overhead of task execution.

[0081] This application embodiment also provides a task processing device 12, such as Figure 12 As shown, Figure 12 A schematic diagram of a task processing device provided in an embodiment of this application is shown. The device may include the following modules.

[0082] Module 10: In response to a task processing request, it retrieves the queue container corresponding to the task to be processed. The queue container holds a serial task queue. The elements in the serial task queue correspond to one of the multiple subtasks of the task to be processed. The order of the elements in the serial task queue corresponds to the task execution order of the multiple subtasks. First creation module 20: When there is a target element in the serial task queue, it is used to create a task group corresponding to the target element based on multiple preceding elements that the target element depends on. The execution of the target subtask corresponding to the target element depends on the function execution of the preceding subtask corresponding to the preceding element. The second creation module 30 is used to create task semaphores corresponding to task groups. The count value of the task semaphore represents the task completion amount of each preceding subtask corresponding to multiple preceding elements. The maximum count value of the task semaphore corresponds to the number of preceding elements in the task group. Trigger module 40: In response to the count value reaching the maximum count value, it triggers the scheduling and execution of the target subtask to obtain the target execution result.

[0083] In some embodiments, the apparatus may further include the following modules: Reading module: When a target element exists in the serial task queue, before creating the task group corresponding to the target element based on multiple preceding elements that the target element depends on, the elements in the serial task queue are read sequentially. Element Determination Module: When the subtask corresponding to the current element depends on multiple preceding subtasks, the module determines the current element as the target element and the elements corresponding to the multiple preceding subtasks as preceding elements.

[0084] In some embodiments, the apparatus may further include the following modules: Scheduling trigger module: Used to schedule and execute each preceding subtask corresponding to the task group before the target subtask is executed and the target execution result is obtained, in response to the count value reaching the maximum count value. Semaphore update module: Used to update the count value of the task semaphore in response to the completion feedback of the preceding subtask, until the count value reaches the maximum count value.

[0085] In some embodiments, the apparatus may further include the following modules: Semaphore initialization module: Used to initialize the count value of the task semaphore after the scheduled execution of the target subtask is triggered, so as to obtain an empty task semaphore; The second creation module is also used to respond to the creation of the next task group and associate the next task group with the null task semaphore; Semaphore setting module: Used to set the maximum count value of the empty task semaphore based on the number of preceding elements in the next task group, and generate the task semaphore corresponding to the next task group.

[0086] In some embodiments, the apparatus may further include the following modules: Call object retrieval module: used to retrieve the call object of the subtask corresponding to the serial task queue; Object wrapper module: Used to wrap the calling object into a wrapper object of a preset type; Reference creation module: Used to create reference relationships between encapsulated objects and the task execution results of subtasks.

[0087] In some embodiments, the apparatus may further include a lifecycle setting module: after encapsulating the calling object into a predefined encapsulation object, in response to the scheduling trigger of the subtask, setting the lifecycle of the encapsulation object, wherein the lifecycle represents the upper limit of the duration for which the calling object corresponding to the encapsulation object is locked. In some embodiments, the trigger module 40 includes: Precedence Result Acquisition Submodule: Used to obtain the execution results of each preceding subtask based on the reference relationship of the encapsulated objects of each preceding subtask; Target reference creation submodule: Used to create the target reference relationship between the encapsulated object of the target subtask and the result of the preceding execution; The scheduling and execution submodule is used to schedule and execute target subtasks based on target reference relationships, taking the results of each preceding execution as input, and obtain the target execution result.

[0088] In some embodiments, the acquisition module 10 includes: The task call information acquisition submodule is used to respond to task processing requests and obtain the task call information of the task to be processed. The task call information includes the task execution order and task dependencies of multiple subtasks. The queue container creation submodule is used to create queue containers corresponding to tasks to be processed. The queue containers hold an initial serial queue. The task addition submodule is used to add subtasks that have task dependencies to an initial serial queue in sequence, based on the task execution order and task dependencies, to obtain a serial task queue.

[0089] In some embodiments, the queue container also holds an initial concurrent queue, and the task adding submodule is also used to add subtasks that do not have task dependencies to the initial concurrent queue based on task dependencies, thereby obtaining a concurrent task queue.

[0090] In some embodiments, the apparatus may further include the following modules: Concurrent scheduling module: used to concurrently schedule and execute subtasks corresponding to the concurrent task queue; Duration detection module: used to detect the scheduling and execution duration of subtasks corresponding to the concurrent task queue; Log writing module: When the scheduled execution time exceeds the preset time, in response to the execution error of the subsequent subtask, the task execution information of the subtask that has exceeded the preset time is written to the task log of the task to be processed.

[0091] In some embodiments, the apparatus may further include a wrapper object creation module: creating empty wrapper objects at the head and / or tail of an initial serial queue, the empty wrapper objects being used for data transmission in the serial task queue.

[0092] It should be noted that the above-described device embodiments and method embodiments are based on the same implementation methods.

[0093] This application provides a task processing device, which can be a terminal or a server, including a processor and a memory. The memory stores at least one instruction or at least one program, which is loaded and executed by the processor to implement the task processing method provided in the above method embodiments.

[0094] Memory is used to store software programs and modules. The processor executes various functional applications and tasks by running the software programs and modules stored in memory. Memory can primarily include a program storage area and a data storage area. The program storage area stores the operating system, application programs required for functions, etc.; the data storage area stores data created based on device usage, etc. Furthermore, memory can include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device. Accordingly, memory may also include a memory controller to provide the processor with access to the memory.

[0095] The methods and embodiments provided in this application can be executed in electronic devices such as mobile terminals, computer terminals, servers, or similar computing devices. Figure 13 This is a hardware structure block diagram of an electronic device for a task processing method provided in an embodiment of this application. For example... Figure 13 As shown, the electronic device 900 can vary significantly due to different configurations or performance. It may include one or more Central Processing Units (CPUs) 910 (CPUs 910 may include, but are not limited to, microprocessors such as MCUs or programmable logic devices such as FPGAs), a memory 930 for storing data, and one or more storage media 920 (e.g., one or more mass storage devices) for storing application programs 923 or data 922. The memory 930 and storage media 920 may be temporary or persistent storage. The program stored in the storage media 920 may include one or more modules, each module including a series of instruction operations on the electronic device. Furthermore, the CPU 910 may be configured to communicate with the storage media 920 and execute a series of instruction operations in the storage media 920 on the electronic device 900. The electronic device 900 may also include one or more power supplies 960, one or more wired or wireless network interfaces 950, one or more input / output interfaces 940, and / or one or more operating systems 921, such as Windows Server. TM Mac OS X TM Unix TM Linux™, FreeBSD™, etc.

[0096] The input / output interface 940 can be used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the electronic device 900. In one example, the input / output interface 940 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the input / output interface 940 may be a radio frequency (RF) module used for wireless communication with the Internet.

[0097] Those skilled in the art will understand that Figure 13 The structure shown is for illustrative purposes only and does not limit the structure of the electronic device described above. For example, the electronic device 900 may also include... Figure 13 The more or fewer components shown, or having the same Figure 13 The different configurations shown.

[0098] Embodiments of this application also provide a computer-readable storage medium, which can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a task processing method in the method embodiment. The at least one instruction or the at least one program is loaded and executed by the processor to implement the task processing method provided in the above method embodiment.

[0099] Optionally, in this embodiment, the storage medium may be located at at least one of the multiple network servers in a computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0100] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various alternative implementations described above.

[0101] As can be seen from the embodiments of the task processing method, apparatus, device, server, terminal, storage medium, and program product provided in this application, in response to a task processing request, this application obtains a queue container corresponding to the task to be processed. The queue container holds a serial task queue, and the elements in the serial task queue correspond to one of the multiple subtasks of the task to be processed. The order of the elements in the serial task queue corresponds to the task execution order of the multiple subtasks, so that the task to be processed can be managed through the queue container and the serial task queue. In a multi-threaded task scenario, this facilitates unified task detection. Then, if a target element exists in the serial task queue, a task group corresponding to the target element is created based on the multiple preceding elements that the target element depends on, and a task semaphore corresponding to the task group is created. The count value of the task semaphore represents the task completion amount of each preceding subtask corresponding to the multiple preceding elements, and the maximum count value of the task semaphore corresponds to the number of preceding elements in the task group. Then, in response to the count value reaching the maximum count value, the scheduling and execution of the target subtask is triggered to obtain the target execution result. In this way, by using queues and semaphores to block and synchronize thread tasks, adaptive configuration of multi-threaded task updates can be achieved, avoiding call errors caused by function iterations such as SDK additions or updates, while making full use of resources and reducing the resource overhead of task execution.

[0102] It should be noted that the order of the embodiments described above is merely for descriptive purposes and does not represent the superiority or inferiority of the embodiments. Furthermore, the above description focuses on specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps described in the claims can be performed in a different order than that shown in the embodiments and still achieve the desired results. Additionally, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired results. In some implementations, multitasking and parallel processing are also possible or may be advantageous.

[0103] The various embodiments in this application are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the device, equipment, and storage medium embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0104] Those skilled in the art will understand that all or part of the steps of the above embodiments can be implemented by hardware, or by a program instructing the relevant hardware to implement them. The program can be stored in a computer-readable storage medium, such as a read-only memory, a disk, or an optical disk.

[0105] The above are merely preferred embodiments of this application and are not intended to limit this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A task processing method, characterized in that, The method includes: In response to a task processing request, a queue container corresponding to the task to be processed is obtained. The queue container holds a serial task queue. The elements in the serial task queue correspond to one of the multiple subtasks of the task to be processed. The order of the elements in the serial task queue corresponds to the task execution order of the multiple subtasks. The task to be processed is split into multiple subtasks based on the granularity of function calls. If a target element exists in the serial task queue, a task group corresponding to the target element is created based on multiple preceding elements that the target element depends on. The execution of the target subtask corresponding to the target element depends on the function execution of the preceding subtask corresponding to the preceding element. If the serial task queue includes multiple branches, multiple task groups are created in parallel. Create a task semaphore corresponding to the task group. The count value of the task semaphore represents the task completion amount of each preceding subtask corresponding to the plurality of preceding elements. The maximum count value of the task semaphore corresponds to the number of preceding elements of the task group. The preceding subtasks in the task group are scheduled to be executed concurrently. After any preceding subtask is completed, the count value of the task semaphore is incremented by 1. In response to the count value reaching the maximum count value, the scheduling and execution of the target subtask are triggered to obtain the target execution result.

2. The method according to claim 1, characterized in that, Before creating a task group corresponding to the target element based on multiple preceding elements that the target element depends on, when a target element exists in the serial task queue, the method further includes: Read the elements in the serial task queue sequentially; If the subtask corresponding to the current element depends on multiple preceding subtasks, the current element is determined as the target element, and the elements corresponding to the multiple preceding subtasks are determined as the preceding elements.

3. The method according to claim 1, characterized in that, Before triggering the scheduled execution of the target subtask in response to the count value reaching the maximum count value and obtaining the target execution result, the method further includes: Schedule and execute each preceding subtask corresponding to the task group; In response to the completion feedback of the preceding subtask, the count value of the task semaphore is updated until the count value reaches the maximum count value.

4. The method according to claim 1, characterized in that, After triggering the scheduled execution of the target subtask, the method further includes: Initialize the count value of the task semaphore to obtain the empty task semaphore; In response to the creation of the next task group, associate the next task group with the empty task semaphore; The maximum count value of the empty task semaphore is set based on the number of preceding elements in the next task group, and the task semaphore corresponding to the next task group is generated.

5. The method according to claim 3, characterized in that, The method further includes: Obtain the invocation object of the subtask corresponding to the serial task queue; The calling object is encapsulated into a pre-defined encapsulated object; Create a reference relationship between the encapsulated object and the task execution result of the subtask.

6. The method according to claim 5, characterized in that, After encapsulating the calling object into a wrapper object of a preset type, the method further includes: In response to the scheduling trigger of the subtask, the lifecycle of the encapsulated object is set, wherein the lifecycle represents the upper limit of the duration during which the calling object corresponding to the encapsulated object is locked.

7. The method according to claim 5, characterized in that, The process of triggering the scheduling and execution of the target subtask to obtain the target execution result includes: Based on the reference relationship of the encapsulation objects of each preceding subtask, the execution result of each preceding subtask is obtained; Create a target reference relationship between the encapsulated object of the target subtask and the result of the preceding execution; Based on the target reference relationship, the target subtask is scheduled and executed using the results of each preceding execution as input, and the target execution result is obtained.

8. The method according to any one of claims 1-7, characterized in that, The step of obtaining the queue container corresponding to the task to be processed in response to the task processing request includes: In response to the task processing request, the task invocation information of the task to be processed is obtained, the task invocation information including the task execution order and task dependency relationship of the multiple subtasks; Create a queue container corresponding to the task to be processed, and the queue container holds an initial serial queue; Based on the task execution order and the task dependencies, subtasks with task dependencies among the multiple subtasks are added sequentially to the initial serial queue to obtain the serial task queue.

9. The method according to claim 8, characterized in that, The queue container also holds an initial concurrent queue, and the method further includes: Based on the task dependencies, subtasks that do not have task dependencies among the multiple subtasks are added to the initial concurrent queue to obtain a concurrent task queue.

10. The method according to claim 9, characterized in that, The method further includes: The subtasks corresponding to the concurrent task queue are concurrently scheduled and executed; Detect the scheduling and execution time of the subtasks corresponding to the concurrent task queue; If the scheduled execution time exceeds the preset time, in response to the execution error of the subsequent subtask, the task execution information of the subtask that exceeded the preset time is written into the task log of the task to be processed.

11. The method according to claim 8, characterized in that, The method further includes: An empty encapsulation object is created at the head and / or tail of the initial serial queue. The empty encapsulation object is used for data transmission in the serial task queue.

12. A task processing device, characterized in that, The device includes: Acquisition module: In response to a task processing request, acquires a queue container corresponding to the task to be processed. The queue container holds a serial task queue. The elements in the serial task queue correspond to one of the multiple subtasks of the task to be processed. The order of the elements in the serial task queue corresponds to the task execution order of the multiple subtasks. The task to be processed is split into multiple subtasks based on the granularity of function calls. First creation module: When a target element exists in the serial task queue, it creates a task group corresponding to the target element based on multiple preceding elements that the target element depends on, wherein the execution of the target subtask corresponding to the target element depends on the function execution of the preceding subtask corresponding to the preceding element; and when the serial task queue includes multiple branches, it creates multiple task groups in parallel. The second creation module is used to create a task semaphore corresponding to the task group. The count value of the task semaphore represents the task completion amount of each preceding subtask corresponding to the multiple preceding elements. The maximum count value of the task semaphore corresponds to the number of preceding elements in the task group. The preceding subtasks in the task group are concurrently scheduled and executed. After any preceding subtask is completed, the count value of the task semaphore is incremented by 1. Triggering module: In response to the count value reaching the maximum count value, trigger the scheduling and execution of the target subtask to obtain the target execution result.

13. The apparatus according to claim 12, characterized in that, The device further includes: Reading module: When a target element exists in the serial task queue, before creating a task group corresponding to the target element based on multiple preceding elements that the target element depends on, the module sequentially reads the elements in the serial task queue. Element determination module: When the subtask corresponding to the current element depends on multiple preceding subtasks, the current element is determined as the target element, and the elements corresponding to the multiple preceding subtasks are determined as the preceding elements.

14. The apparatus according to claim 12, characterized in that, The device further includes: Scheduling trigger module: used to schedule and execute each preceding subtask corresponding to the task group before the target subtask is scheduled and executed in response to the count value reaching the maximum count value and before the target execution result is obtained; Semaphore update module: In response to the completion feedback of the preceding subtask, update the count value of the task semaphore until the count value reaches the maximum count value.

15. The apparatus according to claim 12, characterized in that, The device further includes: Semaphore initialization module: used to initialize the count value of the task semaphore after the scheduling execution of the target subtask is triggered, so as to obtain an empty task semaphore; The second creation module is also used to associate the next task group with the empty task semaphore in response to the creation of the next task group; Semaphore setting module: used to set the maximum count value of the empty task semaphore based on the number of preceding elements of the next task group, and generate the task semaphore corresponding to the next task group.

16. The apparatus according to claim 14, characterized in that, The device further includes: Call object acquisition module: used to acquire the call object of the subtask corresponding to the serial task queue; Object encapsulation module: used to encapsulate the calling object into an encapsulation object of a preset type; Reference creation module: Used to create a reference relationship between the encapsulated object and the task execution result of the subtask.

17. The apparatus according to claim 16, characterized in that, The device also includes a lifecycle setting module: This is used to set the lifecycle of the encapsulated object in response to the scheduling trigger of the subtask after the calling object is encapsulated into an encapsulated object of a preset type. The lifecycle represents the upper limit of the duration during which the calling object corresponding to the encapsulated object is locked.

18. The apparatus according to claim 16, characterized in that, The triggering module includes: Precedence Result Acquisition Submodule: Used to obtain the preceding execution results of each preceding subtask based on the reference relationship of the encapsulated objects of each preceding subtask; Target reference creation submodule: Used to create the target reference relationship between the encapsulated object of the target subtask and the result of the preceding execution; The scheduling and execution submodule is used to schedule and execute the target subtask based on the target reference relationship and with the results of each preceding execution as input, so as to obtain the target execution result.

19. The apparatus according to any one of claims 12-18, characterized in that, The acquisition module includes: The task call information acquisition submodule is used to obtain the task call information of the task to be processed in response to the task processing request. The task call information includes the task execution order and task dependency relationship of the multiple subtasks. Queue Container Creation Submodule: Used to create a queue container corresponding to the task to be processed, wherein the queue container holds an initial serial queue; Task Addition Submodule: Based on the task execution order and the task dependency relationship, add the subtasks that have task dependencies to the initial serial queue in sequence to obtain the serial task queue.

20. The apparatus according to claim 19, characterized in that, The queue container also holds an initial concurrent queue, and the task adding submodule is further used for: Based on the task dependencies, subtasks that do not have task dependencies among the multiple subtasks are added to the initial concurrent queue to obtain a concurrent task queue.

21. The apparatus according to claim 20, characterized in that, The device further includes: Concurrent scheduling module: used to concurrently schedule and execute subtasks corresponding to the concurrent task queue; Duration detection module: used to detect the scheduling and execution duration of the subtasks corresponding to the concurrent task queue; Log writing module: When the scheduled execution time exceeds the preset time, in response to the execution error of the subsequent subtask, the task execution information of the subtask that has exceeded the preset time is written into the task log of the task to be processed.

22. The apparatus according to claim 19, characterized in that, The device also includes an encapsulated object creation module: Used to create empty encapsulation objects at the head and / or tail of the initial serial queue, the empty encapsulation objects being used for data transmission in the serial task queue.

23. A computer-readable storage medium, characterized in that, The storage medium stores at least one instruction or at least one program segment, which is loaded and executed by a processor to implement the task processing method as described in any one of claims 1-11.

24. A computer device, characterized in that, The device includes a processor and a memory, the memory storing at least one instruction or at least one program, the at least one instruction or the at least one program being loaded and executed by the processor to implement the task processing method as described in any one of claims 1-11.

25. A computer program product, characterized in that, The computer program product includes computer instructions that, when executed by a processor, implement the task processing method as described in any one of claims 1-11.

Images