Task scheduling method and device, electronic equipment, computer readable storage medium and computer program product

Abstract

The invention provides a task scheduling method and device, electronic equipment, a computer program product and a computer readable storage medium. The task scheduling method is applied to a game engine, and the game engine comprises multiple types of threads. The method comprises the steps of obtaining a pre-created task description file; the task description file comprises task information of a plurality of tasks, and the task information is defined based on a coroutine function and an anonymous function; determining first task information of the first to-be-scheduled task from the task description file, wherein the first task information at least comprises first post return information; determining a first thread type based on the first post return information; and obtaining a first thread of the idle first thread type, and executing the first to-be-scheduled task on the first thread based on the first task information. According to the invention, the task scheduling and execution efficiency can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and particularly relates to a task scheduling method and device, electronic equipment, computer readable storage medium and computer program product. BACKGROUND

[0002] In the design of a game engine, game logic is usually run in the main loop of the main thread through the way of subroutine call. With the improvement of game picture quality, the game logic calculation work required for drawing a frame of game picture is significantly increased.

[0003] In the related art, a user manually converts part of the game logic calculation task in the game engine, that is, a specific calculation is split into several independent executable sub-processes. For example, the game engine Unreal Engine uses an asynchronous task processing system (Task Graph) for parallel processing of tasks.

[0004] However, the above-mentioned task parallel method involves synchronization between tasks, and generally uses a blocking wait and an explicit lock to solve the task synchronization problem, but reduces the performance of the game engine and thus reduces the task execution efficiency. SUMMARY

[0005] The embodiments of the present application provide a task scheduling method and device, electronic equipment, computer readable storage medium and computer program product, which can improve the task scheduling and execution efficiency.

[0006] The technical solution of the embodiments of the present application is as follows:

[0007] The embodiments of the present application provide a task scheduling method, applied to a game engine, wherein the game engine includes multiple types of threads; the method comprises the following steps: obtaining a pre-created task description file; the task description file includes task information of multiple tasks, and the task information is obtained based on a coroutine function and an anonymous function definition; determining first task information of a first to-be-scheduled task from the task description file, wherein the first task information at least includes first post-return information; determining a first thread type based on the first post-return information; obtaining an idle first thread of the first thread type, and executing the first to-be-scheduled task on the first thread based on the first task information.

[0008] The embodiment of the present application provides a task scheduling device, the device comprises: a task description module, used for acquiring a pre-created task description file; the task description file comprises task information of a plurality of tasks, and the task information is obtained based on a coroutine function and an anonymous function definition; a task acquisition module, used for determining first task information of a first to-be-scheduled task from the task description file, wherein the first task information at least comprises first post-return information; a thread type determination module, used for determining a first thread type based on the first post-return information; and a task execution module, used for acquiring an idle first thread of the first thread type, and executing the first to-be-scheduled task on the first thread based on the first task information.

[0009] In the above scheme, when the first task information comprises a preceding task, the thread type determination module is further used for acquiring an execution state of the preceding task; and when the execution state of the preceding task is completion, a first thread type is determined based on the first post-return information.

[0010] In the above scheme, the thread type determination module is further used for determining that the first thread type is a task type and a master type when the first post-return information comprises scheduling interface information; and determining that the first thread type is an asynchronous type when the first post-return information comprises asynchronous interface information.

[0011] In the above scheme, the task execution module is further used for determining the master type thread as the first thread when the first thread type is the task type and the master type, and the master type thread is idle; determining an idle task type thread as the first thread when the first thread type is the task type and the master type, and the master type thread is not idle; and determining an idle asynchronous type thread as the first thread when the first thread type is the asynchronous type.

[0012] In the above scheme, when the first task information comprises second task information of a second to-be-scheduled task, the task execution module is further used for pausing execution of the first to-be-scheduled task when execution of the first to-be-scheduled task on the first thread reaches the second to-be-scheduled task; the second to-be-scheduled task is created by using a coroutine function; second post-return information of the second to-be-scheduled task is acquired from the task description file; a second thread type is determined based on the second post-return information; an idle second thread of the second thread type is acquired, and the second to-be-scheduled task is executed on the second thread based on the second task information; and when the second to-be-scheduled task is executed completely, an idle first thread of the first thread type is acquired, and the first to-be-scheduled task is continued to be executed on the third thread.

[0013] In the above scheme, the task scheduling apparatus further comprises a variable updating module, configured to: when the first task information comprises a variable captured by an anonymous function from a third to-be-scheduled task and a first variable value, and the third task information of the third to-be-scheduled task comprises an execution statement for the variable, determine third post-return information of the third to-be-scheduled task from the task description file; determine a third thread type based on the third post-return information, and acquire a fourth thread of the third thread type that is idle; when the third post-return information comprises an integer type, execute the third to-be-scheduled task on the fourth thread, and cover the first variable value in the first task information with an execution result of the execution statement based on the first variable value; acquire a fifth thread of the first thread type that is idle, and execute the first to-be-scheduled task on the fifth thread based on the first task information.

[0014] In the above scheme, the task scheduling apparatus further comprises a concurrency module, configured to: determine task information of at least two to-be-scheduled tasks that are executed concurrently from the task description file; determine a thread type of each to-be-scheduled task based on the task information of each to-be-scheduled task; acquire an idle thread of each thread type based on the thread type of each to-be-scheduled task; and execute each to-be-scheduled task concurrently on the corresponding idle thread based on the task information of each to-be-scheduled task.

[0015] An electronic device is provided in an embodiment of the present application, and the electronic device comprises: a memory configured to store computer executable instructions or a computer program; and a processor configured to execute the computer executable instructions or the computer program stored in the memory to implement the task scheduling method provided in the embodiments of the present application.

[0016] A computer readable storage medium is provided in an embodiment of the present application, and the computer readable storage medium stores a computer program or computer executable instructions, and is configured to be executed by a processor to implement the task scheduling method provided in the embodiments of the present application.

[0017] A computer program product is provided in an embodiment of the present application, and the computer program product comprises a computer program or computer executable instructions, and the computer program or computer executable instructions are executed by a processor to implement the task scheduling method provided in the embodiments of the present application.

[0018] The embodiments of the present application have the following beneficial effects:

[0019] In the task scheduling process of the game engine, a pre-created task description file can be acquired, first task information of a first to-be-scheduled task is determined from the task description file, and a first thread type is determined based on first post-return information in the first task information. The first to-be-scheduled task is executed on a first thread of the first thread type based on the first task information. Embodiments of the present application independently define the task description and the task execution as two processes, define the task information using the coroutine function and the anonymous function, which can facilitate the definition of the to-be-executed task and the thread type where the task is executed. After the task description file is created, the game engine can automatically allocate different tasks to different types of threads for execution based on the task description file, improve the efficiency of task scheduling, and thus can implement different threads to execute different tasks, improve the performance of the game engine and the efficiency of task execution. BRIEF DESCRIPTION OF DRAWINGS

[0020] Figure 1 is an architecture schematic diagram of a task configuration system provided by embodiments of the present application;

[0021] Figure 2 is a structure schematic diagram of an electronic device provided by embodiments of the present application;

[0022] Figure 3 is a first flow schematic diagram of a task scheduling method provided by embodiments of the present application;

[0023] Figure 4 is a second flow schematic diagram of a task scheduling method provided by embodiments of the present application;

[0024] Figure 5 is a third flow schematic diagram of a task scheduling method provided by embodiments of the present application;

[0025] Figure 6 is a fourth flow schematic diagram of a task scheduling method provided by embodiments of the present application;

[0026] Figure 7 is a fifth flow schematic diagram of a task scheduling method provided by embodiments of the present application;

[0027] Figure 8 is a schematic diagram of a performance debugging framework provided by embodiments of the present application;

[0028] Figure 9 is an architecture design diagram of a task scheduling system for task execution provided by embodiments of the present application.

[0029] It should be noted that the above-mentioned "first", "second" are only used to distinguish different schemes, and do not represent the degree of superiority or priority in the implementation process. DETAILED DESCRIPTION

[0030] In order to make the purposes, technical solutions and advantages of the present application clearer, the following further describes the present application in conjunction with the accompanying drawings, the described embodiments should not be regarded as limiting the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0031] In the following description, "some embodiments" are referred to, which describe a subset of all possible embodiments, but it can be understood that "some embodiments" can be the same subset or different subsets of all possible embodiments, and can be combined with each other without conflict.

[0032] In the following description, the term "first\second\third" is only to distinguish similar objects, and does not represent a specific order of the objects, and it can be understood that "first\second\third" can be interchanged with a specific order or sequence as allowed, so that the embodiments of the present application described herein can be implemented in an order other than that illustrated or described herein.

[0033] In the embodiments of the present application, the term "module" or "unit" refers to a computer program or a part of a computer program with a predetermined function, and works with other related parts to achieve a predetermined target, and can be implemented entirely or partially by using software, hardware (such as a processing circuit or a memory) or a combination thereof. Similarly, one processor (or multiple processors or memories) can be used to implement one or more modules or units. In addition, each module or unit can be a part of an integral module or unit that includes the functions of the module or unit.

[0034] Unless otherwise defined, all technical and scientific terms used in the embodiments of the present application have the same meanings as those commonly understood by those skilled in the art. The terms used in the embodiments of the present application are only for the purpose of describing the embodiments of the present application and are not intended to limit the present application.

[0035] The relevant data collection process in the embodiments of the present application should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and within the scope of authorization of laws and regulations and the personal information subject, carry out subsequent data use and processing.

[0036] Before the embodiments of the present application are further described in detail, the terms and terms involved in the embodiments of the present application are explained, and the terms and terms involved in the embodiments of the present application are applicable to the following explanations.

[0037] 1) Game Engine: The core component of an editable game system or real-time interactive image application, it provides game designers with various tools needed to write game programs, making it easier for game developers to create electronic games. Game engines usually support the implementation of the following functions: physical calculation, determination of light and shadow effects, collision detection, rendering of game elements, generation of sound effects, running of game scripts, etc.

[0038] 2) Task: Various game logic calculation processes that need to be performed in the game engine. For example, tasks can include graphics rendering tasks, physics simulation tasks, artificial intelligence (AI) calculation tasks, network communication tasks, etc. The game engine needs to manage the scheduling and execution of these tasks to ensure the smoothness and performance of the game.

[0039] 3) Task Scheduling: An important function in the game engine, it is used to arrange and manage the execution order and priority of various tasks, ensuring that various tasks are executed in a timely manner according to the established logic and priority, thereby ensuring the smoothness and performance of the game.

[0040] 4) Subroutine: Also known as a subprogram, it is a part of a large program composed of one or more statement blocks. Subroutines are responsible for completing a task and have relative independence compared to other code.

[0041] 5) Process: A running activity of a program on a data collection in a computer, it is the basic unit of resource allocation for the system and the foundation of the operating system structure.

[0042] 6) Thread: In computer science, it is the division of a process into two or more threads (instances) or sub-processes, which are executed concurrently by a single processor (single thread) or multiple processors (multi-thread) or multi-core processing system.

[0043] 7) Coroutine: A component of a computer program used to implement multi-task concurrent execution in program design. Coroutines promote cooperative multi-task subroutines, allowing execution to be suspended and resumed, i.e., switching between multiple tasks within a single thread. Compared to subroutines, coroutines are more general and flexible.

[0044] 8) Anonymous Function: In computer programming, it refers to a class of functions or subroutines that do not need to define identifiers (function names), which are widely used in various programming languages, especially in C++ as Lambda Expressions.

[0045] 9)Blocking Wait: Used for handling asynchronous task processing in game engines, allowing the game engine to put the current task (or thread) into a waiting state when waiting for certain resources or events, so as not to consume CPU resources. When the waiting condition is met, the task will be reawakened and continue to execute.

[0046] 10)Explicit Locks: A mechanism for synchronizing concurrent threads accessing shared resources, which requires users to manually acquire and release. In scenarios where users add explicit locks, multiple threads or tasks cannot access shared resources simultaneously and can only be executed in a certain order. That is, only one thread or task can access shared resources at a time, and other threads or tasks must wait until the current thread or task is completed. This serial execution approach can avoid race conditions and data inconsistency problems that may occur when multiple threads access shared resources simultaneously. However, this also leads to low task execution efficiency.

[0047] In the design of traditional game engines, there is no concept of task scheduling, and game logic is run in the main loop of the main thread through subroutine calls. With the improvement of game picture quality, the preparation work required to draw a frame has significantly increased, and the game engine usually strips the drawing-related calculations to a separate dedicated thread, which implements a two-level pipeline of logic and drawing, which can theoretically double the frame rate (FPS). With the increasing richness and detail of games, the game engine design gradually introduces the concept of tasks, i.e., breaking down a specific calculation into several independent executable sub-processes to fully utilize the increasing number of CPU cores to speed up calculations. For example, the game engine Unreal Engine uses an asynchronous task processing system (Task Graph) for parallel processing of tasks. Such concurrent programming naturally involves task synchronization, which is usually solved using blocking wait and explicit locks. In summary, the above-mentioned task scheduling methods of game engines have the following shortcomings:

[0048] 1、In the related art, the code of a game engine runs in a single thread, and although the architecture is simple and clear, the multi-core performance of the CPU is seriously wasted. Dividing the rendering work into a dedicated thread or parallel processing of the computing task can improve the performance of the game engine, but for the entire game engine, the proportion of tasks that can be parallel computed is low, and the multi-core performance of the CPU is still not fully utilized. In addition, using the blocking waiting method will further reduce the performance, and for the scene with explicit locks, even if the user can correctly analyze and implement the relevant code, the tasks will still be executed in series, resulting in low execution efficiency. That is, there is still a problem of low performance of the game engine and low efficiency of task execution.

[0049] 2、In the above method, the user generally needs to manually manage the tasks, increasing the complexity of game development and the difficulty of code maintenance. If the user needs to modify the execution mode of the task, the code usually needs to be refactored, so the flexibility of the system is low, and the system also lacks corresponding debugging facilities.

[0050] Based on the problems existing in the above related technology, the embodiments of the present application provide a task scheduling method, device, electronic equipment, computer readable storage medium and computer program product, which is a task scheduling method based on coroutines, and can improve the task scheduling and execution efficiency.

[0051] Among them, the task scheduling method provided by the embodiments of the present application is applied to a game engine, and the game engine includes multiple types of threads. First, a pre-created task description file is obtained; the task description file includes task information of multiple tasks, and the task information is obtained based on coroutine functions and anonymous functions; then, first task information of a first to-be-scheduled task is determined from the task description file, and the first task information at least includes first post-return information; the first thread type is determined based on the first post-return information; finally, an idle first thread of the first thread type is obtained, and the first to-be-scheduled task is executed on the first thread based on the first task information.

[0052] An exemplary application of the task scheduling device provided by the embodiments of the present application, which is an electronic device for implementing the task scheduling method, will be described below. The electronic device provided by the embodiments of the present application can be implemented as various types of terminals such as a notebook computer, a tablet computer, a desktop computer, a set-top box, a smart phone, a smart speaker, a smart watch, a smart television, a vehicle-mounted terminal, and the like, or as a server. The server can be a standalone physical server, a server cluster or a distributed system composed of multiple physical servers, or a cloud server providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and basic cloud computing services such as big data and artificial intelligence platforms. The terminals and the server can be connected directly or indirectly through wired or wireless communication, which is not limited in the embodiments of the present application. Exemplary applications of the task scheduling device implemented as a server or a terminal will be described below.

[0053] Referring to Figure 1 , Figure 1 is an architecture diagram of a task configuration system provided by the embodiments of the present application. To perform a task scheduling operation, a task scheduling application can be provided, which can be an application dedicated to task scheduling or a functional module in other applications (such as a task scheduling module in a game engine, etc.). The task configuration system 100 of the embodiments of the present application at least includes a terminal 400, a network 300, and a server 200, wherein the server 200 is a server of a payment application. The server 200 can constitute a task scheduling device of the embodiments of the present application, that is, the server 200 implements the task scheduling method of the embodiments of the present application. The terminal 400 connects to the server 200 through the network 300, and the network 300 can be a wide area network or a local area network, or a combination of the two.

[0054] Referring to Figure 1The user can perform an interactive operation, such as a click start operation, on the client of the game engine through the terminal 400. After receiving the interactive operation of the user, the terminal 400 receives the task description file created by the user in advance, encapsulates the task description file into a task scheduling request, and sends the task scheduling request to the server 200 through the network 300. After receiving the task scheduling request, the server 200 obtains the task description file created in advance in response to the task scheduling request sent by the terminal. The task description file includes task information of multiple tasks, and the task information is obtained based on a coroutine function and an anonymous function definition. The server 200 determines first task information of a first to-be-scheduled task from the task description file, and the first task information at least includes first post-return information. The server 200 determines a first thread type based on the first post-return information. The server 200 obtains an idle first thread of the first thread type, executes the first to-be-scheduled task on the first thread based on the first task information. After all the tasks in the task description file are scheduled and executed, the server 200 can also generate a task scheduling result based on the scheduling and execution of all the tasks. The server 200 sends the task scheduling result to the terminal 400, so as to display the task scheduling result on the current interface of the client of the terminal 400.

[0055] In some embodiments, the task scheduling method of the present application can also be executed by the terminal 400 itself, that is, after the terminal 400 receives the interactive operation input by the user through the client, the terminal 400 obtains the task description file created in advance. The task description file includes task information of multiple tasks, and the task information is obtained based on a coroutine function and an anonymous function definition. The terminal 400 determines first task information of a first to-be-scheduled task from the task description file, and the first task information at least includes first post-return information. The terminal 400 determines a first thread type based on the first post-return information. The terminal 400 obtains an idle first thread of the first thread type, executes the first to-be-scheduled task on the first thread based on the first task information. After all the tasks in the task description file are scheduled and executed, the terminal 400 can also generate a task scheduling result based on the scheduling and execution of all the tasks. The task scheduling result is displayed on the current interface of the client of the terminal 400.

[0056] The task scheduling method provided in the embodiments of the present application can also be implemented based on a cloud platform and through cloud technology. For example, the server 200 can be a cloud server. The cloud server responds to a task scheduling request sent by a terminal to obtain a pre-created task description file. Alternatively, the cloud server determines first task information of a first to-be-scheduled task from the task description file. Alternatively, the cloud server determines a first thread type based on the first post-return information. Alternatively, the cloud server obtains an idle first thread of the first thread type, and executes the first to-be-scheduled task on the first thread based on the first task information.

[0057] In some embodiments, a cloud storage can also be provided, and the pre-created task description file can be stored in the cloud storage. In this way, when a task scheduling request is received, the task description file can be directly obtained from the cloud storage, the task is scheduled based on the task description file, and the task scheduling efficiency is improved.

[0058] It should be noted that the cloud technology refers to a hosting technology that unifies a series of resources such as hardware, software, and network to realize data calculation, storage, processing, and sharing in a wide area network or a local area network. The cloud technology is a general term of network technology, information technology, integration technology, management platform technology, and application technology applied based on a cloud computing business model, can form a resource pool, and is used on demand, flexibly and conveniently. The cloud computing technology will become an important support. The background service of a technical network system needs a large amount of calculation and storage resources, such as a video website, a picture website, and more portals. With the high development and application of the Internet industry, in the future, each item can have its own identification mark and needs to be transmitted to a background system for logical processing. Different levels of data will be processed separately, and data of various industries needs strong system support, which can be realized through cloud computing.

[0059] Referring to Figure 2 , Figure 2 is a structural schematic diagram of an electronic device provided by the embodiments of the present application, Figure 2 The terminal 400 shown in FIG. 4 includes at least one processor 410, a memory 450, at least one network interface 420, and a user interface 430. The various components in the terminal 400 are coupled together through a bus system 440. It can be understood that the bus system 440 is used to realize the connection and communication between the components. In addition to a data bus, the bus system 440 also includes a power bus, a control bus, and a status signal bus. However, for the purpose of clear illustration, all kinds of buses are marked as the bus system 440 in the Figure 2

[0060] ​The processor 410 can be an integrated circuit chip that has a processing capability of signals, such as a general purpose processor, a digital signal processor (DSP), or other programmable logic device, discrete gate or transistor logic device, discrete hardware component, etc., wherein the general purpose processor can be a microprocessor or any conventional processor.

[0061] The user interface 430 includes one or more output devices 431 that enable presentation of media content, including one or more speakers and one or more visual display screens. The user interface 430 also includes one or more input devices 432 that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0062] The memory 450 can be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state memory, hard drives, optical drives, etc. The memory 450 optionally includes one or more storage devices physically located in proximity to the processor 410.

[0063] The memory 450 includes volatile memory or non-volatile memory, and can also include both volatile and non-volatile memory. Non-volatile memory can be read only memory (ROM), volatile memory can be random access memory (RAM). The memory 450 described in the embodiments of the present application is intended to include any suitable type of memory.

[0064] In some embodiments, the memory 450 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or a subset or superset thereof, which are exemplarily illustrated below.

[0065] The operating system 451 includes system programs for processing various basic system services and performing hardware-related tasks, such as a framework layer, a core library layer, a driver layer, etc., for implementing various basic services and processing hardware-based tasks;

[0066] The network communication module 452 is used to communicate with other electronic devices via one or more (wired or wireless) network interfaces 420, exemplary network interfaces 420 include Bluetooth, wireless compatibility authentication (WiFi), and universal serial bus (USB), etc.

[0067] A presentation module 453 for enabling presentation of information (e.g., a user interface for operating a peripheral device and displaying content and information) via one or more output devices 431 (e.g., a display screen, a speaker, etc.) associated with the user interface 430;

[0068] An input processing module 454 for detecting and interpreting one or more user inputs or interactions from one or more input devices 432.

[0069] In some embodiments, the apparatus provided by the embodiments of the present application can be implemented in software, Figure 2 A task scheduling apparatus 455 stored in the memory 450 is shown, which can be software in the form of programs and plug-ins, etc., including the following software modules: a task description module 4551, a task acquisition module 4552, a thread type determination module 4553, and a task execution module 4554. These modules are logical, and thus can be combined or further split according to the implemented functions. The functions of the various modules will be described below.

[0070] In some embodiments, the apparatus provided by the embodiments of the present application can be implemented in software,

[0071] It should be noted that the following examples of the task scheduling method are described in the context of game development, and those skilled in the art can apply the task scheduling method provided by the embodiments of the present application to other scenarios using game engine technology, such as interactive multimedia, simulation systems, educational tools, simulators and consoles (e.g., Full Flight Simulator (FFS) visual software systems), real-time three-dimensional visualization, etc.

[0072] Figure 3 is a first flowchart of a task scheduling method provided by an embodiment of the present application. The task scheduling method is applied to a game engine, and the game engine includes multiple types of threads. The following will be described in combination with the steps shown in Figure 3 FIG. 1, as shown in FIG. 1, a task scheduling method is executed by a server as an execution subject, and the method includes the following steps S101 to S104: Figure 3

[0073] Step S101, a pre-created task description file is obtained.

[0074] The task description file includes task information of multiple tasks, and the task information is defined based on a coroutine function and an anonymous function.

[0075] Here, the game engine can include a task scheduling system, which is used to schedule a to-be-scheduled task based on a task description file. The to-be-scheduled task is a task waiting to be executed in the game engine. An object (for example, a user who develops a game using the game engine) can create a task description file on a client of the game engine. The task description file includes task information of multiple tasks. A task refers to a calculation process in the running of the game engine, such as a rendering task, a drawing task, a file loading task, etc. That is, a calculation that needs to use resources can be regarded as a task. The object can define each task based on a coroutine function and an anonymous function in advance to obtain corresponding task information. The task information can include a dependency relationship and a priority between multiple tasks, an execution thread type of each task, etc. The task information can also include specific business logic defined by the anonymous function, such as physical settlement, animation update, and drawing command generation, etc.

[0076] ​The object can create a task description file using a coroutine mechanism of a C++20 programming language. The C++20 has a coroutine library, which includes a plurality of coroutine functions. A coroutine function is a function for creating a coroutine, which allows a task to be paused and resumed during execution, enabling parallelism and cooperation of tasks. In the C++20, a coroutine function can include a function co_await, a function co_yield, and the like. The embodiments of the present application do not make a detailed description of the same. An anonymous function is a function expression without a name, which is usually used to quickly create a temporary function in a programming language. In the C++20, an anonymous function is a lambda expression, and the object can define a task using the lambda expression. The object defines task information of the task by combining a coroutine function and an anonymous function. For example, in the C++20, a coroutine call can be initiated using a Coro coroutine in a manner of a lambda expression (anonymous function), a task coro0 is defined, and the defined task information is as follows: threading: :coro({ptr0, ptr1}, [magic=43]()→threading: :coroDispatchPtr<>{…coro0…}).

[0077] In step S102, first task information of a first to-be-scheduled task is determined from the task description file.

[0078] The first task information at least includes first post-return information.

[0079] Here, the first to-be-scheduled task can be a task that is first invoked and executed in the task description file. The first post-return information is information for specifying a return result type after execution of the first to-be-scheduled task is completed, and specifying a thread type of the first to-be-scheduled task. The first post-return information is generally a coroutine keyword or a coroutine instruction included in the coroutine library.

[0080] In step S103, a first thread type is determined based on the first post-return information.

[0081] Here, the first thread type is a type of thread that can execute the first to-be-scheduled task. The thread types in the task scheduling system can include a master type, a task type, and an asynchronous type. The master type thread is the initial initiator and scheduler of the task, the task type thread is mainly used to execute parallel tasks within a frame, and the asynchronous type thread is used to process long tasks across frames, and each type of thread has a unique priority setting. A frame refers to the time used to update and display a game screen once. Parallel tasks refer to at least two tasks that can be executed simultaneously. For example, a physics settlement task in a game screen is executed by a task type thread. A task in at least two game screens, such as a file loading task that needs to be loaded from the first frame to the tenth frame, is a long task across frames, which is processed by an asynchronous type thread. The master type thread is used to execute main tasks of the game engine during game development, such as rendering tasks and rendering tasks. The master type thread can also automatically split tasks into multiple small to-be-scheduled tasks and distribute them to other type threads for execution.

[0082] In the task scheduling system, different thread types correspond to different interfaces. The master type thread and the task thread can be called through a calling interface (Dispatch interface). The asynchronous type thread can be called through an asynchronous interface (Async interface). The first post-return information can include interface information. After obtaining the interface information from the first post-return information, the first thread type is determined based on the interface information.

[0083] In some embodiments, when the first task information includes a pre-task, referring to Figure 4 , Figure 4 The step of determining the first thread type based on the first post-return information in step S103 can be implemented through the following steps S1031 to S1032:

[0084] Step S1031, obtaining the execution state of the pre-task.

[0085] Here, the pre-task is a task that the first to-be-scheduled task depends on, i.e., a task that must be executed before the first to-be-scheduled task is executed. The execution state of the pre-task can include to-be-executed, executing, and completed, etc. The object can add the pre-task in the task information through the lambda expression (anonymous function) in C++20, for example, the task information threading: : coro({ptr0, ptr1}, [magic = 43]() -> threading: : coroDispatchPtr<>{…coro0…}) of the task coro0, {ptr0, ptr1} is the pre-task, i.e., after the tasks ptr0 and ptr1 are executed, the task coro0 can be executed.

[0086] In step S1032, when the execution state of the preceding task is completed, the first thread type is determined based on the first post-return information.

[0087] Here, when the execution state of the preceding task is completed, the first to-be-scheduled task can be scheduled and executed, and the first thread type is determined based on the first post-return information.

[0088] The embodiment of the present application can realize the execution order constraint between any tasks by the preceding dependency by adding the preceding task in the task information, and improve the flexibility of task scheduling.

[0089] In some embodiments, the first thread type is determined based on the first post-return information in step S103, which can also be realized by the following manner: when the first post-return information includes the scheduling interface information, the first thread type is determined as the task type and the master type; or when the first post-return information includes the asynchronous interface information, the first thread type is determined as the asynchronous type.

[0090] For example, the task information of the task coro0 is threading: : coro({ptr0, ptr1}, [magic=43]()→threading: : coroDispatchPtr<>{…coro0…}), wherein the coroDispatchPtr< > is the first post-return information. The Dispatch is the scheduling interface information, and the first post-return information of the coro0 includes the scheduling interface information, so the first thread type of the coro0 can be determined as the task type and the master type. If the first post-return information of the coro1 includes the asynchronous interface information coro AsyncPtr< >, the first thread type of the coro1 can be determined as the asynchronous type.

[0091] The embodiment of the present application can realize the execution of the tasks with different priorities by the distribution to the threads of the corresponding type by using the scheduling interface information and the asynchronous interface information in the task information, so that the game engine can automatically allocate different tasks to the threads of different types based on the task description file, improve the efficiency of task scheduling, and then realize the execution of different tasks by different threads, and improve the performance of the game engine and the efficiency of task execution.

[0092] In step S104, the idle first thread of the first thread type is obtained, and the first to-be-scheduled task is executed on the first thread based on the first task information.

[0093] Here, the task scheduling system can include one master type thread, multiple task type threads, and multiple asynchronous type threads. The number of threads can be set by the object itself. After determining the first thread type corresponding to the first to-be-scheduled task, an idle first thread of the first thread type can be obtained, and the first to-be-scheduled task can be executed on the first thread based on the first task information. The first task information includes the specific business logic of the first to-be-scheduled task, and the corresponding instructions can be executed on the first thread based on the business logic.

[0094] In the embodiment of the application, the idle first thread of the first thread type obtained in step S104 can be implemented in the following manner: when the first thread type is the task type and the master type, and the master type thread is idle, the master type thread is determined as the first thread; when the first thread type is the task type and the master type, and the master type thread is not idle, the idle task type thread is determined as the first thread; when the first thread type is the asynchronous type, the idle asynchronous type thread is determined as the first thread.

[0095] Here, idle means that the thread has no task being executed. When the first thread type of the first to-be-scheduled task is the task type and the master type, the performance of the master type thread is better, so when the master type thread is idle, the master type thread can be determined as the first thread. The first to-be-scheduled task is scheduled to the master type thread, and the first to-be-scheduled task is executed on the master type thread based on the first task information. When the master type thread is not idle, an idle task type thread can be randomly obtained as the first thread. The first to-be-scheduled task is scheduled to the idle task type thread, and the first to-be-scheduled task is executed on the task type thread based on the first task information. When the first thread type is the asynchronous type, an idle asynchronous type thread can be randomly obtained as the first thread.

[0096] It should be noted that in another embodiment, if all threads are in a non-idle state, the scheduling of the subsequent first to-be-scheduled task can be suspended until there is an idle thread of the first thread type to resume the scheduling. Alternatively, the number of tasks waiting to be executed in the threads of the first thread type can be obtained, the first to-be-scheduled task is scheduled to the thread of the first thread type with the smallest number of tasks, and a task queue is constructed to wait for thread calling.

[0097] The embodiment of the application can automatically assign different tasks to different types of threads for execution, improve the efficiency of task scheduling, and thus can implement different threads executing different tasks, improve the performance of the game engine and the efficiency of task execution.

[0098] In some embodiments, when the first task information includes second task information of a second to-be-scheduled task, referring to Figure 5 , Figure 5The step S104 of executing the first to-be-scheduled task on the first thread based on the first task information can be implemented through the following steps S1041 to S1045.

[0099] The step S1041 suspends the execution of the first to-be-scheduled task when the execution of the second to-be-scheduled task is performed in the process of executing the first to-be-scheduled task on the first thread.

[0100] The second to-be-scheduled task is created by using a coroutine function. Here, the coroutine function refers to a function co_await used to suspend the current execution task. The object can create the second to-be-scheduled task by using the coroutine function co_await in the first task information of the first to-be-scheduled task, and define the second task information of the second to-be-scheduled task by using an anonymous function. The definition process of the second task information of the second to-be-scheduled task is similar to that of the first task information, which will not be described here in detail. When the execution of the first to-be-scheduled task is performed to the second to-be-scheduled task created by the coroutine function co_await, the execution of the first to-be-scheduled task is suspended. For example, a new task coro1 is called by the coroutine function co_await in the task coro0, threading: : coro({ptr0, ptr1}, [magic = 43]() -> threading: : coroDispatchPtr<>{... coro0; co_await threading: : coro([]() -> coroAsyncPtr<... coro1...>)}. At this time, when the execution is performed to the statement co_await threading: : coro([]() -> coroAsyncPtr<... coro1...>), the execution of the task coro0 is suspended.

[0101] The step S1042 obtains the second post-return information of the second to-be-scheduled task from the task description file.

[0102] The definition and example of the second post-return information and the obtaining process can be referred to the aforementioned first post-return information, which will not be described here again.

[0103] The step S1043 determines the second thread type based on the second post-return information.

[0104] Here, the specific process of determining the second thread type based on the second post-return information is similar to that of the step S103, which will not be described here again.

[0105] The step S1044 obtains an idle second thread of the second thread type, and executes the second to-be-scheduled task on the second thread based on the second task information.

[0106] Here, the second thread of the second thread type is acquired, and a specific process of executing the second to-be-scheduled task on the second thread based on the second task information is similar to step S104, and thus is not repeated.

[0107] Step S1045, when the second to-be-scheduled task is executed, a third thread of the first thread type is acquired, and the first to-be-scheduled task is continued to be executed on the third thread.

[0108] Here, the execution state of the second to-be-scheduled task can be acquired, and when the execution state of the second to-be-scheduled task is completed, the third thread of the first thread type is re-acquired. It should be noted that the third thread and the first thread can be the same thread or different threads. The first to-be-scheduled task is continued to be executed on the third thread based on the first task information.

[0109] The embodiment of the application can realize the temporary suspension of the current task, the execution of other tasks, the task switching execution in the thread, and the flexibility of the task scheduling system is improved.

[0110] In the task scheduling process of the game engine, the task description file created in advance can be acquired, the first task information of the first to-be-scheduled task is determined from the task description file, the first thread type is determined based on the first post-return information in the first task information. The first to-be-scheduled task is executed on the first thread of the idle first thread type. The embodiment of the application separates the task description and the task execution of the task into two processes, uses the coroutine function and the anonymous function to define the task information of the task, can conveniently define the task to be executed and the thread type of the task execution, after the task description file is created, the game engine can automatically allocate different tasks to different types of threads for execution based on the task description file, the efficiency of the task scheduling is improved, and then different threads can execute different tasks, the performance of the game engine and the task execution efficiency are improved.

[0111] In some embodiments, when the first task information includes the variable captured by the anonymous function from the third to-be-scheduled task and the first variable value, and the third task information of the third to-be-scheduled task includes the execution statement for the variable, referring to Figure 6 , Figure 6 It is shown that after step S104, the task scheduling method provided by the embodiment of the application includes the following steps S201 to S204:

[0112] Step S201, the third post-return information of the third to-be-scheduled task is determined from the task description file.

[0113] Here, if the first task information includes a variable, the first to-be-scheduled task performs logical operation according to the variable value of the variable when executing. The first variable value is a value defined by the object when the variable first appears. If the variable in the third task information of the third to-be-scheduled task is the same as the variable in the first task information, and the third to-be-scheduled task includes an execution statement for the variable, the execution of the third to-be-scheduled task will change the variable value of the variable. After the execution of the third to-be-scheduled task is completed, when the first to-be-scheduled task is executed again, the first to-be-scheduled task will capture the return result of the execution of the third to-be-scheduled task as a new variable value, and perform logical operation according to the new variable value. In the embodiment of the present application, the specific process of determining the third post-return information of the third to-be-scheduled task from the task description file is of the type of step S102, and will not be repeated here.

[0114] For example, in the task information threading: : coro({ptr0, ptr1}, [magic = 43]()→threading: : coroDispatchPtr<>{…coro0…}) of the first to-be-scheduled task coro0, [magic = 43] is the variable information, magic is the variable, and 43 is the first variable value.

[0115] In step S202, the third thread type is determined based on the third post-return information, and a fourth thread of the idle third thread type is obtained.

[0116] Here, the specific process of determining the third thread type based on the third post-return information and obtaining the fourth thread of the idle third thread type is similar to step S103, which will not be repeated here.

[0117] In step S203, when the third post-return information includes an integer type, the third to-be-scheduled task is executed on the fourth thread, and the execution result of the execution statement based on the first variable value is used to overwrite the first variable value in the first task information.

[0118] Here, the integer type can be identified by a preset identifier <int>The preset identifier of the integer type is generally located at the end of the post-return information. If the preset identifier of the integer type exists in the third post-return information, it indicates that the return result of the third to-be-scheduled task is a variable value. The execution statement of the third to-be-scheduled task can be executed based on the first variable value to obtain an execution result as the return result of the third to-be-scheduled task. The return result can be used to overwrite the original first variable value, and the first to-be-scheduled task can be executed based on the new first variable value.

[0119] For example, the first task information of the first to-be-scheduled task coro0 is threading::coro({ptr0, ptr1}, [magic=43]()→threading::coroDispatchPtr<>{…coro0…}), the variable is magic, and the first variable value is 43. The third post-return information of the third to-be-scheduled task coro2 is coroDispatchPtr <int>, the execution statement is co_return magic-1. Then a third to-be-scheduled task coro2 is executed on an idle master thread or a task thread, the execution statement magic-1 is executed based on the first variable value 43, an execution result 42 is obtained, and 42 is taken as a new first variable value.

[0120] In step S204, a fifth thread of the first thread type is obtained, and the first to-be-scheduled task is executed on the fifth thread based on the first task information.

[0121] For example, the first to-be-scheduled task is executed on the fifth thread based on the new first variable value 42. The fifth thread can be the same thread as the first thread or a different thread.

[0122] The embodiments of the present application can update the variable value in the execution process of the task by defining the variable in the task information, thereby implementing more business logic calculations, implementing the overall task of the game engine, and improving the task scheduling efficiency and the execution efficiency.

[0123] In some embodiments, referring to Figure 7 , Figure 7 The task scheduling method provided by the embodiments of the present application is shown to include the following steps S301 to S304:

[0124] In step S301, the task information of at least two to-be-scheduled tasks to be executed concurrently is determined from a task description file.

[0125] Here, concurrent execution means that the to-be-scheduled tasks can be executed simultaneously. If there is a preset coroutine instruction Coros in the task description file, the task information of at least two to-be-scheduled tasks to be executed concurrently can be obtained from the coroutine instruction Coros. The task information is obtained by defining a coroutine function and an anonymous function. Objects can be executed simultaneously based on the coroutine function co_await multiple to-be-scheduled tasks through the coroutine instruction Coros in the C++20 coroutine library in the task description file.

[0126] For example, if there is co_await Coros(Coro(...coro3-1...), Coro(...coro3-2…)) in the task description file, the to-be-scheduled tasks coro3-1 and coro3-2 can be executed concurrently.

[0127] In step S302, the thread type of each to-be-scheduled task is determined based on the task information of each to-be-scheduled task.

[0128] Here, the specific process of determining the thread type based on the task information for each to-be-scheduled task is the same as that in step S103, and will not be described in detail.

[0129] Step S303, based on the thread type of each to-be-scheduled task, respectively acquire the idle threads of each thread type.

[0130] Here, for each to-be-scheduled task, the specific process of determining the idle thread based on the thread type is the same as step S104, and will not be described in detail.

[0131] Step S304, based on the task information of each to-be-scheduled task, concurrently execute each to-be-scheduled task on the corresponding idle thread.

[0132] For example, the to-be-scheduled task coro3-1 can be executed on the idle task type thread 1 based on the task information, and at the same time, the to-be-scheduled task coro3-2 can be executed on the idle task type thread 2 based on the task information.

[0133] In the embodiment of the application, the object can add the task information of at least two to-be-scheduled tasks that can be concurrently executed in the task description file through the coroutine, so that the game engine can implement concurrent execution of the tasks. Compared with serial execution of the tasks, concurrent execution can execute multiple tasks at the same time, thereby improving the task execution efficiency and the game engine performance.

[0134] In the following, an exemplary application of the embodiment of the application in an actual application scenario will be described.

[0135] The task scheduling method proposed in the embodiment of the application is applied to a game engine task scheduling system based on a coroutine, and a runtime execution model of a game engine is implemented. The model not only enables a user to conveniently define tasks to be executed, but also provides efficient scheduling for the execution of the tasks. In the execution model, the embodiment of the application distinguishes the concepts of task description and task execution, i.e., the two concepts exist independently, while in a traditional game engine, the task description and the task execution are bound together. The embodiment of the application defines tasks using a coroutine, including task description and task execution. The task description mainly defines specific business logic using an anonymous function, such as object resolution, animation update, and drawing command generation, etc. The task execution includes two aspects: execution dependency of the task and execution thread and priority of the task. In particular, the embodiment of the application uses the coroutine mechanism provided by C++20 to implement the execution model. The embodiment of the application also designs and supports using interfaces such as a call interface (Dispatch) and an asynchronous interface (Async) to initiate tasks defined by a conventional anonymous function. Furthermore, the two types of tasks can be mixed and used interactively. The embodiment of the application uses the coroutine mechanism of the C++20 programming language to define tasks, and the coroutine mechanism is implemented by interfaces such as the call interface and the asynchronous interface.

[0136] In the execution model proposed in the embodiments of the present application, threads are divided into three categories: master threads, task threads and asynchronous threads. The master thread is the initial initiator and scheduler of the task, the task thread is mainly used to execute the parallel task in the frame, and the asynchronous thread is used to process the long task across frames, and each type of thread has a unique priority setting. The execution model can flexibly configure the number of threads of each type without modifying any user code, facilitating performance and problem debugging. The task scheduling system of the embodiments of the present application also includes a performance debugging framework, which facilitates the access of any performance debugger, provides the possibility of visual task scheduling, and enables users to intuitively analyze the performance of the code.

[0137] The following illustrates the task description in the task scheduling method provided by the embodiments of the present application. Similar to the usage of the calling interface and the asynchronous interface, in C++20, a coroutine call can be initiated by using a lambda expression (anonymous function) of Coro coroutine, for example, threading: : coro({ptr0, ptr1}, [magic = 43]() -> threading: : coroDispatchPtr<> {…coro0…}). Wherein, {ptr0, ptr1} is the specified pre-dependence, that is, before the task coro0 is executed, tasks ptr0 and ptr1 need to be completed first. In the actual task description, the pre-dependence can also not be specified. However, the return type of the coroutine must be specified in the task description using the post-return type, that is, coroDispatchPtr<>. coroDispatchPtr< > represents that the coro0 coroutine (task) will be executed on the thread schedulable by the scheduling interface (Dispatch interface). The thread schedulable by the scheduling interface is the master thread (Master Threads) and the task thread (Task Threads). [magic = 43] is the capture used in the lambda expression, that is, magic is the variable captured by coro0, and 43 is the variable value of the variable magic. The lambda expression capture can be directly used in the Coro coroutine as long as the same life cycle principle as the calling interface and the asynchronous interface is followed, that is, the life cycle of the captured object is longer than the execution of the task. See Figure 8 , the horizontal axis is the time axis, and the task execution process includes the calling thread (Calling Thread), the master thread (Master Threads), the task thread (Task Threads) and the asynchronous thread (Async Thread). The calling thread is used to start calling the task in the task description, that is, to initiate the coro0 coroutine call in the above example. The coro0 task is allocated to a task thread to start execution.

[0138] If a new coroutine corol is called by a coroutine function co_await in the coroutine coroO, for example, threading::coro({ptrO, ptrl}, [magic=43]() -> threading::coroDispatchPtr<>{... coroO; co_await threading::coro([]() -> coroAsyncPtr<... corol>}). See Figure 8 At this time, the execution flow of the current coroutine coroO is transferred to the new coroutine corol, and since the post-return type of the coroutine corol is coroAsyncPtr<>, coroAsyncPtr< > represents that the corol coroutine (task) will be executed on an asynchronous interface (Async interface) schedulable thread. The asynchronous interface schedulable thread is an asynchronous thread (Async Threads). Therefore, the corol task is assigned to an asynchronous thread to start execution. Until the new coroutine corol is executed, the current coroutine coroO is re-assigned to a task thread to resume execution.

[0139] The post-return type can also be <int>Unlike <>, <int>The coroutine is declared to have a return value and of the integer type int. For example, a coroutine coro2 can be called, and the post return type of the coroutine coro2 is written as coroDispatchPtr <int>, and there is a statement co_return magic-1 in the coroutine coro2. See Figure 8 The task coro2 is assigned to a task thread to start execution. The return result of the execution is the variable value 43-1=42 of the variable magic in the preceding task coro1. Then, the task coro1 is assigned to a task thread and starts execution based on the new variable value 42 of the variable magic.

[0140] The Coros instruction can also be used to simultaneously co_await multiple coro coroutines, which are executed concurrently. For example Figure 8 In the coro3-1 and coro3-2 are executed concurrently. Note that co_await Coro(...); co_await Coro(...); is not equivalent to co_await Coros(Coro(...), Coro(...)), because the two Coros in the former are executed sequentially. The above task description example embodies the convenience and freedom of the user using the Application Programming Interface (API) provided by the embodiments of the present application.

[0141] See Figure 9 , Figure 9 is an architecture design diagram of a task scheduling system for task execution provided by an embodiment of the present application. The task scheduling system uses a hierarchical structure, which is composed of a bottom layer, a basic interface 502 (API), and a coroutine library 501. The bottom layer mainly consists of two parts: thread management 504 and a scheduler 503. The thread management 504 is responsible for the life cycle control of various threads (main control thread, task thread, asynchronous thread), priority attribute configuration, and debugging information recording, etc. The scheduler 503 implements an efficient scheduling algorithm for various tasks, manages different task queues, and has high scalability, which can support cross-platform use and adaptive optimization for different platforms. Under the support of the bottom layer, the task scheduling system implements the basic interface 502, of which the most core is the scheduling interface, the asynchronous interface, and the explicit waiting task interface (WaitForTasks). The scheduling interface and the asynchronous interface can distribute user-defined tasks of different priorities to appropriate types of threads for execution through the scheduler, and at the same time, the user can (optionally) constrain the execution order between any tasks through the pre-dependence manner. The tasks called by the scheduling interface are scheduled to the main control thread or the task thread for execution, while the asynchronous interface is in the asynchronous thread. The explicit waiting task interface provides a mechanism for explicitly waiting for other tasks in the current task. If the waited task is not completed when called, the explicit waiting task interface will grab appropriate other unrelated tasks for execution through the scheduler. In order to improve the ease of use, the basic interface also designs interfaces such as the parallel loop interface (ParallelFor) to support common parallel programming paradigms. The coroutine library 501 (Coro, Coros, CoroTaskptr, CoroAsyncptr are all function instructions in the coroutine library) in the task scheduling system uses C++20 programming language, which opens a set of mechanisms. The developers of the task scheduling system can define the use mode and execution process of the coroutine through defining the asynchronous promise type (Promise type) and the co_await operator, and then the embodiment of the present application builds the execution model of the general task in the game engine using the coroutine on the basis of the capabilities provided by the basic interface.

[0142] The embodiments of the present application distinguish the concepts of task description and task execution, define tasks using coroutine anonymous functions, and consider the overall architecture of complete tasking from the engine, thereby providing the possibility of full multi-core CPU utilization. According to the embodiments of the present application, a user can write highly parallelized code in a linear manner through the provided interface, without the need for manual task management, and further, using different levels of interfaces, the user can choose to use more traditional or more modern task scheduling methods to meet the needs of games of different complexities. When using the embodiments of the present application to process synchronization problems of multiple tasks, the user usually does not need to explicitly use the synchronization operations commonly used in the related art, which improves the correctness and performance of the code, and at the same time, allows the user to focus more on the definition and design of the task itself, thereby improving the overall code quality. Finally, the embodiments of the present application also provide a performance debugging framework to facilitate the user to understand and debug highly parallel programs.

[0143] It can be understood that, in the embodiments of the present application, data related to user information is involved, and when the embodiments of the present application are applied to specific products or technologies, user permission or consent is required, and the collection, use and processing of related data need to comply with relevant laws, regulations and standards.

[0144] The following continues to describe an exemplary structure of the task scheduling apparatus 455 provided by the embodiments of the present application, which is implemented as a software module. In some embodiments, as shown in FIG. 4, the software module stored in the task scheduling apparatus 455 of the memory 450 can include: Figure 2 The task description module 4551 is configured to obtain a pre-created task description file. The task description file includes task information of a plurality of tasks, and the task information is obtained based on coroutine functions and anonymous functions. The task obtaining module 4552 is configured to determine first task information of a first to-be-scheduled task from the task description file, and the first task information at least includes first post-return information. The thread type determining module 4553 is configured to determine a first thread type based on the first post-return information. The task execution module 4554 is configured to obtain an idle first thread of the first thread type, and execute the first to-be-scheduled task on the first thread based on the first task information.

[0145] In the above scheme, when the first task information includes a pre-task, the thread type determining module 4553 is further configured to obtain an execution state of the pre-task. When the execution state of the pre-task is complete, the first thread type is determined based on the first post-return information.

[0146] In the above scheme, the thread type determining module 4553 is further configured to determine that the first thread type is a task type and a master type when the first post-return information includes scheduling interface information, and determine that the first thread type is an asynchronous type when the first post-return information includes asynchronous interface information.

[0147] In the above scheme, the task execution module 4554 is further configured to: when the first thread type is the task type and the master type, and the master type thread is idle, determine the master type thread as the first thread; when the first thread type is the task type and the master type, and the master type thread is not idle, determine an idle task type thread as the first thread; and when the first thread type is the asynchronous type, determine an idle asynchronous type thread as the first thread.

[0148] In the above scheme, when the first task information includes second task information of a second to-be-scheduled task, the task execution module 4554 is further configured to: when executing the first to-be-scheduled task on the first thread, pause execution of the first to-be-scheduled task when reaching the second to-be-scheduled task; the second to-be-scheduled task is created by using a coroutine function; obtain second post-return information of the second to-be-scheduled task from the task description file; determine a second thread type based on the second post-return information; obtain an idle second thread of the second thread type, and execute the second to-be-scheduled task on the second thread based on the second task information; and when the second to-be-scheduled task is executed, obtain an idle third thread of the first thread type, and continue to execute the first to-be-scheduled task on the third thread.

[0149] In the above scheme, the task scheduling apparatus 455 further includes a variable updating module, configured to: when the first task information includes a variable captured by an anonymous function from a third to-be-scheduled task and a first variable value, and the third to-be-scheduled task includes an execution statement for the variable in third task information of the third to-be-scheduled task, determine third post-return information of the third to-be-scheduled task from the task description file; determine a third thread type based on the third post-return information, and obtain an idle fourth thread of the third thread type; when the third post-return information includes an integer type, execute the third to-be-scheduled task on the fourth thread, and cover the first variable value in the first task information with an execution result of the execution statement based on the first variable value; obtain an idle fifth thread of the first thread type, and execute the first to-be-scheduled task on the fifth thread based on the first task information.

[0150] In the above scheme, the task scheduling apparatus 455 further includes a concurrency module, configured to: determine task information of at least two to-be-scheduled tasks to be executed concurrently from the task description file; determine a thread type of each to-be-scheduled task based on the task information of each to-be-scheduled task; obtain an idle thread of each thread type based on the thread type of each to-be-scheduled task; and execute each to-be-scheduled task concurrently on the corresponding idle thread based on the task information of each to-be-scheduled task.

[0151] The embodiment of the present application provides a computer program product, which comprises a computer program or computer executable instructions stored in a computer readable storage medium. The processor of the electronic device reads the computer executable instructions from the computer readable storage medium, and the processor executes the computer executable instructions, so that the electronic device executes the task scheduling method provided by the embodiment of the present application.

[0152] The embodiment of the present application provides a computer readable storage medium, which stores computer executable instructions or computer programs. When the computer executable instructions or computer programs are executed by a processor, the processor executes the task scheduling method provided by the embodiment of the present application, for example, the task scheduling method shown in the embodiment of the present application. Figure 3 The task scheduling method is shown.

[0153] In some embodiments, the computer readable storage medium can be RAM, ROM, flash memory, magnetic surface memory, optical disc, or CD-ROM memory, etc. It can also be various devices including one or any combination of the above storage.

[0154] In some embodiments, the computer executable instructions can be in the form of programs, software, software modules, scripts or codes, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and can be deployed in any form, including being deployed as independent programs or being deployed as modules, components, subroutines or other units suitable for use in a computing environment.

[0155] As an example, the computer executable instructions can but not necessarily correspond to files in a file system, can be stored in a part of a file storing other programs or data, for example, stored in one or more scripts in a Hyper Text Markup Language (HTML) document, stored in a single file dedicated to the program in question, or stored in multiple cooperative files (for example, files storing one or more modules, subroutines or code parts).

[0156] As an example, the computer executable instructions can be deployed to execute on one electronic device, or on multiple electronic devices located in one place, or on multiple electronic devices distributed in multiple places and interconnected through a communication network.

[0157] In summary, the embodiments of the present application distinguish the concepts of task description and task execution, separate the task execution from the task description, provide the possibility for designing a highly parallel game engine, and improve the task scheduling and execution efficiency. For the task description, the embodiments of the present application support multiple ways including coroutines and ordinary anonymous functions, can meet different needs of users, and improve the flexibility and ease of use of parallel code design. For the implementation of the task execution, the embodiments of the present application adopt a clear layered architecture design, provide a highly configurable API, and can meet the performance requirements in different scenarios; on the core bottom design, a unique thread classification concept is proposed and an efficient scheduling algorithm is implemented. Meanwhile, the embodiments of the present application support cross-platform use and make specific optimizations for the target platform. Finally, since a highly parallel program is difficult to understand and debug, the embodiments of the present application also provide a performance debugging framework to help users understand and debug the game engine.

[0158] The above merely illustrates the embodiments of the present application, and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, and improvement within the spirit and scope of the present application shall be included in the protection scope of the present application.< / int> < / int> < / int> < / int> < / int>

Claims

1. A task scheduling method, characterized by, The method is applied to a game engine, and the game engine includes multiple types of threads; the method includes: obtaining a pre-created task description file; the task description file includes task information of multiple tasks, and the task information is obtained based on a coroutine function and an anonymous function definition; determining first task information of a first to-be-scheduled task from the task description file, wherein the first task information at least includes first post-return information; determining a first thread type based on the first post-return information; obtaining an idle first thread of the first thread type, and executing the first to-be-scheduled task on the first thread based on the first task information.

2. The method of claim 1, wherein, When the first task information includes a pre-task, the determination of the first thread type based on the first post-return information includes: obtaining an execution state of the pre-task; when the execution state of the pre-task is complete, determining the first thread type based on the first post-return information.

3. The method according to claim 1 or 2, characterized in that, The determination of the first thread type based on the first post-return information includes: when the first post-return information includes scheduling interface information, determining that the first thread type is a task type and a master type; when the first post-return information includes asynchronous interface information, determining that the first thread type is an asynchronous type.

4. The method of claim 3, wherein, The obtaining of the idle first thread of the first thread type includes: when the first thread type is the task type and the master type, and a master type thread is idle, determining the master type thread as the first thread; when the first thread type is the task type and the master type, and the master type thread is not idle, determining an idle task type thread as the first thread; when the first thread type is the asynchronous type, determining an idle asynchronous type thread as the first thread.

5. The method of claim 1, wherein, When the first task information includes second task information of a second to-be-scheduled task, the execution of the first to-be-scheduled task on the first thread based on the first task information includes: when the execution of the first to-be-scheduled task on the first thread is executed to the second to-be-scheduled task, suspending the execution of the first to-be-scheduled task; the second to-be-scheduled task is created by using a coroutine function; obtaining second post-return information of the second to-be-scheduled task from the task description file; determining a second thread type based on the second post-return information; obtaining an idle second thread of the second thread type, and executing the second to-be-scheduled task on the second thread based on the second task information; when the second to-be-scheduled task is executed, obtaining an idle third thread of the first thread type, and continuing to execute the first to-be-scheduled task on the third thread.

6. The method of claim 1, wherein, When the first task information includes a variable captured by an anonymous function from a third to-be-scheduled task and a first variable value, and third task information of the third to-be-scheduled task includes an execution statement for the variable, after the execution of the first to-be-scheduled task on the first thread, the method further includes: determining third post-return information of the third to-be-scheduled task from the task description file; determine a third thread type based on the third post-return information, and obtain a fourth thread of the third thread type that is idle; when the third post-return information comprises an integer type, execute the third to-be-scheduled task on the fourth thread, and cover the first variable value in the first task information based on an execution result of the execution statement based on the first variable value; obtain a fifth thread of the first thread type that is idle, and execute the first to-be-scheduled task on the fifth thread based on the first task information.

7. The method of claim 1, wherein, The method further comprises: determining task information of at least two to-be-scheduled tasks that are executed concurrently from the task description file; determining a thread type of each to-be-scheduled task based on the task information of each to-be-scheduled task; obtaining an idle thread of each thread type based on the thread type of each to-be-scheduled task; concurrently executing each to-be-scheduled task on the corresponding idle thread based on the task information of each to-be-scheduled task.

8. A task scheduling apparatus characterized by comprising: The apparatus comprises: a task description module configured to obtain a pre-created task description file, wherein the task description file comprises task information of a plurality of tasks, and the task information is defined based on a coroutine function and an anonymous function; a task obtaining module configured to determine first task information of a first to-be-scheduled task from the task description file, wherein the first task information comprises at least first post-return information; a thread type determining module configured to determine a first thread type based on the first post-return information; a task executing module configured to obtain a first thread of the first thread type that is idle, and execute the first to-be-scheduled task on the first thread based on the first task information.

9. An electronic device, comprising: The electronic device comprises: a memory configured to store computer executable instructions or computer programs; a processor configured to execute the computer executable instructions or computer programs stored in the memory to implement the task scheduling method in any one of claims 1 to 7.

10. A computer-readable storage medium storing computer-executable instructions or a computer program, characterized in that, The computer executable instructions or computer programs are executed by the processor to implement the task scheduling method in any one of claims 1 to 7.

11. A computer program product comprising computer-executable instructions or a computer program, characterized in that, The computer executable instructions or computer programs are executed by the processor to implement the task scheduling method in any one of claims 1 to 7. The computer executable instructions or computer programs are executed by the processor to implement the task scheduling method in any one of claims 1 to 7.

Images