A multi-core parallel computing scheduling system and method

Abstract

The present application relates to the field of computer, disclose a kind of multi-core parallel computing scheduling system and method.The thread submodule executes the ticket operation of ticket module when the task ticket balance of ticket module is not zero, exclusively accesses the task ticket generated in ticket module, and the task object corresponding to task ticket is handled;When the task object is handled, if the task ticket balance in ticket module is not zero, ticket is again robbed and the task object corresponding to task ticket is handled again.This embodiment does not need special processing, when the task ticket balance is not zero, each thread exclusively accesses the task ticket by the form of ticket and the task object corresponding to the task ticket robbed is handled, controls multi-core parallel computing by task ticket, avoids the overall performance decline introduced by processing interruption in some core, reduces the waiting time when the task object of thread is handled, makes the system resource utilization more reasonable, improves the overall task performance.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a multi-core parallel computing scheduling system and method. Background Technology

[0002] With the large-scale application of distributed computing, how to rationally allocate computing tasks to improve overall task performance has become a top priority.

[0003] Traditional task scheduling methods predetermine the tasks to be processed by each core. If a core is interrupted in the system to handle the interrupt, some subtasks may be completed very slowly, affecting task performance. Furthermore, when the number of subtasks is disproportionate to the number of cores, special handling is required, which has a certain impact on performance and is prone to errors.

[0004] The above content is only used to help understand the technical solution of the present invention and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this invention is to provide a multi-core parallel computing scheduling system and method, which aims to solve the technical problem in the prior art where the tasks processed by each core are predetermined. If a core in the system is interrupted, it may cause some subtasks to complete particularly slowly, affecting the overall task performance.

[0006] To achieve the above objectives, the present invention provides a multi-core parallel computing scheduling system for parallel processing of multiple tasks. The system includes a ticket module and a thread module; the thread module includes at least two thread sub-modules. The thread submodule is used to perform a ticket grabbing operation on the ticket module based on exclusive access when the remaining task tickets in the ticket module are not zero, so as to obtain task tickets. The thread submodule is also used to process the task object corresponding to the task ticket; The thread submodule is also used to perform a ticket grabbing operation on the ticket module based on exclusive access when the task object is completed and the remaining task tickets in the ticket module are not zero, so as to obtain task tickets.

[0007] Optionally, the thread module is configured to generate a thread sub-module based on the number of task objects corresponding to the task processing request and the number of idle processing units when a task processing request is received.

[0008] Optionally, the thread module is further configured to generate a thread sub-module with the same number of task objects when the number of task objects is less than or equal to the number of idle processing units; The thread module is further configured to generate a thread sub-module with the same number of idle processing units when the number of task objects is greater than the number of idle processing units.

[0009] Optionally, the task object is one of the executable objects contained in a task flow; The ticket module is used to obtain the task information of the task object in the task process when the task process is received; The ticket module is also used to generate the task ticket based on the task information.

[0010] Optionally, the bill module is further configured to query the process information of the task flow when the remaining amount of the bill is zero; The ticket module is also used to generate new task tickets based on the task information of the task objects in other task processes when there are other task processes that depend on the task process.

[0011] Furthermore, to achieve the above objectives, this invention also proposes a multi-core parallel computing scheduling method, which is applied to the scheduling system, the system comprising: a ticket module and a thread module; the thread module comprising at least two thread sub-modules; the method comprising: When the remaining task tickets in the ticket module are not zero, the thread submodule performs a ticket grabbing operation on the ticket module based on exclusive access in order to obtain task tickets. The thread submodule processes the task object corresponding to the task ticket; When the task object is completed, the thread submodule executes the step of performing a ticket grabbing operation on the ticket module based on exclusive access to obtain the task ticket when the remaining task ticket quantity in the ticket module is not zero.

[0012] Optionally, before the step of the thread submodule performing a ticket-grabbing operation on the ticket module based on exclusive access to obtain a task ticket when the remaining task tickets in the ticket module are not zero, the following further step is taken: When the thread module receives a task processing request, it generates a thread sub-module based on the number of task objects corresponding to the task processing request and the number of idle processing units.

[0013] Optionally, when the thread module receives a task processing request, the step of generating a thread sub-module based on the number of task objects corresponding to the task processing request and the number of idle processing units includes: When the number of task objects is less than or equal to the number of idle processing units, the thread module generates a thread sub-module with the same number of task objects. When the number of task objects is greater than the number of idle processing units, the thread module generates a thread sub-module with the same number of idle processing units.

[0014] Optionally, the task object is one of the executable objects included in a task flow; prior to the method, the method further includes: When the bill module receives the task flow, it obtains the task information of the task object in the task flow; The ticket module generates the task ticket based on the task information.

[0015] Optionally, after the thread submodule executes the step of performing a ticket-grabbing operation on the ticket module based on exclusive access to obtain a task ticket when the task object is completed and the remaining task tickets in the ticket module are not zero, the following steps are also included: When the remaining amount of the invoices is zero, the invoice module queries the process information of the task flow. When there are other task flows that depend on the task flow, the ticket module generates a new task ticket based on the task information of the task objects in the other task flows.

[0016] In this invention, when the remaining task tickets are not zero, the thread submodule performs a ticket-grabbing operation on the ticket module, exclusively accessing the task tickets generated in the ticket module and processing the task objects corresponding to the task tickets. When the task object is processed, if the remaining task tickets are not zero, it grabs tickets again and processes the task objects corresponding to the task tickets. This embodiment requires no special processing; each thread exclusively accesses task tickets and processes the task objects corresponding to the grabbed task tickets by grabbing them. By repeating the ticket-grabbing and processing operation, the waiting time when the task objects of the threads are completed is reduced, making the system resources more rationally utilized, improving the efficiency of multi-task parallel processing, and improving the overall task performance. Attached Figure Description

[0017] Figure 1 This is a structural block diagram of the first embodiment of the multi-core parallel computing scheduling system of the present invention; Figure 2 Performance simulation analysis of the multi-core parallel computing scheduling system of this invention Figure 1 ; Figure 3 Performance simulation analysis of the multi-core parallel computing scheduling system of this invention Figure 2 ; Figure 4 This is a flowchart illustrating the first embodiment of the multi-core parallel computing scheduling method of the present invention; Figure 5 This is a flowchart illustrating the second embodiment of the multi-core parallel computing scheduling method of the present invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0020] Reference Figure 1 , Figure 1 This is a structural block diagram of a first embodiment of the multi-core parallel computing scheduling system of the present invention. The multi-core computing scheduling system is used for parallel processing of multiple tasks, and the system includes: a ticket module and a thread module; the thread module includes at least two thread sub-modules. The thread submodule is used to perform a ticket grabbing operation on the ticket module based on exclusive access when the remaining task tickets in the ticket module are not zero, so as to obtain task tickets. The thread submodule is also used to process the task object corresponding to the task ticket; It should be noted that the multi-core parallel computing scheduling system of the present invention is mounted on a terminal device that can be used for parallel task processing. The terminal device can be a personal computer, server, integrated chip, or other device with data processing and task execution functions. This embodiment does not limit this.

[0021] It should be explained that when a multi-core parallel computing scheduling system performs multi-task processing, it is necessary to first generate task tickets for the tasks to be processed. The tasks to be processed can be task flows, which can contain N (N≥2) sub-task objects, each of which is one of the executable objects within the task flow. When the ticket module receives the task flow, it can obtain the task information of the sub-task objects within the task flow and generate sub-task numbers based on the task information of each sub-task object. Corresponding task tickets are then generated based on these sub-task numbers. The tasks to be processed can also be tasks requiring multiple iterations, or other types of tasks. The method for generating task tickets can be determined based on the actual situation, and this embodiment does not impose any restrictions on this.

[0022] It is understandable that a thread module can contain M (M≥2) thread sub-modules, and each thread sub-module can perform task processing operations.

[0023] It should be noted that when a task processing request is received, the thread module can obtain the task object information in the task flow corresponding to the task processing request.

[0024] It should be understood that there are at least two task objects mentioned above. When the thread module obtains task object information, it generates a thread submodule based on the number of idle processing units and the number of task objects to be processed. One way to create a thread submodule is as follows: when the number of task objects is less than or equal to the current number of idle processing units, a thread submodule with the same number of task objects can be created. In this case, the task objects are processed one-to-one through the thread submodule, allowing the processing of each task object to be carried out simultaneously, thus improving the efficiency of task processing.

[0025] Meanwhile, this embodiment of the invention also proposes another way to create thread sub-modules: when the number of task objects is greater than the current number of idle processing units, a thread sub-module with the same number of idle processing units can be created.

[0026] It is understood that the aforementioned processing unit may be the core of the processing device in the aforementioned terminal device, such as the CPU core; the aforementioned idle processing unit is the processing unit in an idle state.

[0027] It should be noted that upon completion of creation, the thread submodule can perform a ticket-grabbing operation on the ticket module based on exclusive access, thereby obtaining the task tickets generated in the ticket module in an exclusive manner.

[0028] It's important to explain that the exclusive access mentioned above refers to the kernel having exclusive access to data at a specific memory address within a certain time period. Performing the ticket-grabbing operation in the form of exclusive access can prevent different thread submodules from obtaining the same task ticket.

[0029] It is understandable that a task ticket corresponds to a task object, and when the thread submodule obtains a task ticket, it can process the task object corresponding to the task ticket.

[0030] In the specific implementation, when the remaining task tickets are not zero, the thread submodule can perform a ticket grabbing operation on the ticket module to obtain the task tickets generated in the ticket module and process the task objects corresponding to the task tickets.

[0031] The thread submodule is also used to perform a ticket grabbing operation on the ticket module based on exclusive access when the task object is completed and the remaining task tickets in the ticket module are not zero, so as to obtain task tickets.

[0032] Understandably, the number of task tickets corresponds to the number of task objects. When a thread submodule acquires a task ticket from the ticket module using exclusive access, the number of task tickets in the ticket module decreases accordingly. When the remaining number of tickets in the ticket module is zero, it indicates that the current task flow has been completed. At this point, the ticket module will query the task flow information. If there are other task flows that depend on the current task flow, new task tickets can be generated based on these other task flows to improve the execution efficiency of the task group. If there are no other task flows that depend on the current task flow, it means that this task request has been completed, and the task processing flow can be terminated.

[0033] It should be noted that when the remaining task tickets are not zero, it means that the task request has not been completed. The ticket module can continue to respond to the ticket grabbing operation of the thread sub-module. When the task object is processed, the thread sub-module can execute the ticket grabbing operation on the ticket module again when the remaining task tickets in the ticket module are not zero, based on exclusive access, to obtain task tickets, until all task tickets are grabbed.

[0034] In the specific implementation, when the thread submodule finishes processing the task object, it executes the operation of grabbing the ticket based on exclusive access to the ticket module when the remaining task ticket quantity in the ticket module is not zero, so as to obtain the task ticket.

[0035] In this embodiment, when the remaining task tickets are not zero, the thread submodule can perform a ticket-grabbing operation on the ticket module, exclusively accessing the task tickets generated in the ticket module and processing the task objects corresponding to the task tickets. When the task object is processed, if the remaining task tickets are not zero, it will grab tickets again and process the task objects corresponding to the task tickets. This embodiment requires no special processing. Each thread exclusively accesses the task tickets and processes the task objects corresponding to the grabbed task tickets by grabbing tickets. By controlling multi-core parallel computing through ticketing, the waiting time when the task objects of the threads are completed is reduced, and the overall performance degradation caused by some cores being interrupted is avoided. This makes the system resources more rationally utilized, improves the efficiency of multi-task parallel processing, and improves the overall task performance.

[0036] Reference Figure 2 and Figure 3 , Figure 2 Performance simulation analysis of the multi-core parallel computing scheduling system of this invention Figure 1 ; Figure 3 Performance simulation analysis of the multi-core parallel computing scheduling system of this invention Figure 2 .

[0037] like Figure 2 and Figure 3 As shown, Figure 2 and Figure 3 The following are performance simulation analysis comparison charts showing the multi-core parallel computing scheduling system proposed in the embodiments of the present invention and the prior art when completing a total number of tasks of 100 and 200 respectively.

[0038] As can be easily seen from the simulation analysis diagrams and the tables above, the multi-core parallel computing scheduling system proposed in this embodiment of the invention significantly reduces the time consumed when completing large amounts of tasks compared to existing systems. The multi-core parallel computing scheduling system proposed in this embodiment of the invention reduces the waiting time when thread task objects are completed, avoids overall performance degradation caused by processing interruptions in certain cores, makes more rational use of system resources, improves the efficiency of multi-task parallel processing, and enhances overall task performance.

[0039] Reference Figure 4 This invention provides a multi-core parallel computing scheduling method for a multi-core parallel computing scheduling system. Figure 4 This is a flowchart illustrating the first embodiment of the multi-core parallel computing scheduling method of the present invention. Its multi-core parallel computing scheduling system includes: a ticket module and a thread module; the thread module includes at least two thread sub-modules; the multi-core parallel computing scheduling method includes: Step S100: When the remaining amount of task tickets is not zero, the thread submodule performs a ticket grabbing operation on the ticket module based on exclusive access to obtain task tickets. It should be noted that the multi-core parallel computing scheduling method of the present invention is used in a multi-core parallel computing scheduling system, which is mounted on a terminal device. This terminal device may include: a processor, such as a central processing unit (CPU), a communication bus, a user interface, a network interface, and memory. The communication bus is used to enable communication between these components. The user interface may include a display screen and an input unit such as a keyboard; optionally, the user interface may also include a standard wired interface or a wireless interface. The network interface may optionally include a standard wired interface or a wireless interface (such as a Wireless-Fidelity (Wi-Fi) interface). The memory may be high-speed random access memory (RAM) or stable non-volatile memory (NVM), such as a disk storage device. Alternatively, the memory may be a storage device independent of the aforementioned processor.

[0040] Those skilled in the art will understand that the structure described above does not constitute a limitation on the terminal device, and may include more or fewer components than described above, or combine certain components, or have different component arrangements.

[0041] It should be noted that when a multi-core parallel computing scheduling system performs multi-task processing, it is necessary to first generate task tickets for the tasks to be processed. The tasks to be processed can be task flows, which can contain N (N≥2) sub-task objects. The ticket module can generate sub-task information based on the task information of each sub-task object, and generate corresponding task tickets based on the sub-task information. The tasks to be processed can also be tasks requiring multiple iterations, or other types of tasks. The method for generating task tickets can be determined according to the actual situation, and this embodiment does not impose any restrictions on it.

[0042] It is understandable that a thread module can contain M (M≥2) thread sub-modules, and each thread sub-module can perform task processing operations.

[0043] It should be noted that the thread submodule can perform ticket grabbing operations on the ticket module based on exclusive access, and obtain the task tickets generated in the ticket module in an exclusive access manner.

[0044] In the specific implementation, when the remaining number of task tickets is not zero, the thread module performs a ticket grabbing operation on the ticket module based on exclusive access to obtain the task ticket.

[0045] Step S200: The thread submodule processes the task object corresponding to the task ticket; It is understandable that a task ticket corresponds to a task object, and when the thread submodule obtains a task ticket, it can process the task object corresponding to the task ticket.

[0046] In the actual implementation, the thread submodule processes the task object corresponding to the task ticket.

[0047] Step S300: When the task object is completed, the thread submodule executes the step of performing a ticket grabbing operation on the ticket module based on exclusive access to obtain the task ticket when the remaining task ticket quantity in the ticket module is not zero.

[0048] Understandably, the number of task tickets corresponds to the number of task objects. When a thread submodule acquires a task ticket from the ticket module based on exclusive access, the number of task tickets in the ticket module decreases accordingly. When the remaining number of task tickets is not zero, it indicates that the task request has not been completed, and the corresponding thread submodule can continue its ticket-grabbing operation. When the task object is processed, the thread submodule can again execute the ticket-grabbing operation on the ticket module based on exclusive access when the remaining number of task tickets in the ticket module is not zero, in order to obtain a task ticket.

[0049] In the specific implementation, when the thread submodule finishes processing the task object, it executes the operation of grabbing the ticket based on exclusive access to the ticket module when the remaining task ticket quantity in the ticket module is not zero, so as to obtain the task ticket.

[0050] In this embodiment, when the remaining task tickets are not zero, the thread submodule can perform a ticket-grabbing operation on the ticket module, exclusively accessing the task tickets generated in the ticket module and processing the task objects corresponding to the task tickets. When the task object is processed, if the remaining task tickets are not zero, it will grab tickets again and process the task objects corresponding to the task tickets. This embodiment does not require special processing. Each thread exclusively accesses the task tickets and processes the task objects corresponding to the grabbed task tickets by grabbing tickets. By controlling multi-core parallel computing through ticketing, the waiting time when the task objects of the threads are completed is reduced, and the overall performance degradation caused by some cores being interrupted is avoided. This makes the system resources more rationally utilized, improves the efficiency of multi-task parallel processing, and improves the overall task performance.

[0051] Based on the first embodiment of the multi-core parallel computing scheduling method of the present invention, a second embodiment of the method is proposed to improve the scheduling efficiency of multi-core parallel computing.

[0052] Reference Figure 5 , Figure 5 This is a flowchart illustrating the second embodiment of the multi-core parallel computing scheduling method of the present invention.

[0053] Before the step of the thread submodule performing a ticket-grabbing operation on the ticket module based on exclusive access to obtain a task ticket when the remaining task tickets in the ticket module are not zero, the following steps are also included: Step S10: When the thread module receives a task processing request, it generates a thread sub-module based on the number of task objects corresponding to the task processing request and the number of idle processing units. Specifically, when the thread module receives a task processing request, the step of generating a thread sub-module based on the number of task objects corresponding to the task processing request and the number of idle processing units includes: Step S11: When the number of task objects is less than or equal to the number of idle processing units, the thread module generates a thread sub-module with the same number of task objects; Step S12: When the number of task objects is greater than the number of idle processing units, the thread module generates a thread sub-module with the same number of idle processing units.

[0054] It should be noted that when a task processing request is received, the thread module can obtain the task object information in the task flow corresponding to the task processing request, and generate a thread sub-module based on the number of idle processing units and the number of task objects to be processed. One way to create a thread sub-module is: when the number of task objects is less than or equal to the current number of idle processing units, a thread sub-module with the same number of task objects can be created. In this case, the task objects are processed one-to-one through the thread sub-module, so that the processing of each task object is carried out simultaneously, thereby improving the efficiency of task processing.

[0055] Meanwhile, this embodiment of the invention also proposes another way to create thread sub-modules: when the number of task objects is greater than the current number of idle processing units, a thread sub-module with the same number of idle processing units can be created.

[0056] It is understood that the aforementioned processing unit may be the core of the processing device in the aforementioned terminal device, such as the CPU core; the aforementioned idle processing unit is the processing unit in an idle state.

[0057] It should be noted that when the thread submodule is created, the thread submodule can perform a ticket grabbing operation on the ticket module based on exclusive access, and obtain the task tickets generated in the ticket module in an exclusive access manner.

[0058] In the specific implementation, when the thread module receives a task processing request, it obtains the number of task objects corresponding to the task processing request. If the number of task objects is less than or equal to the number of idle processing units, it generates a thread submodule with the same number of task objects; if the number of task objects is greater than the number of idle processing units, it generates a thread submodule with the same number of idle processing units.

[0059] Furthermore, the task object is one of the executable objects contained in a task flow; the method described above also includes: Step S01: When the ticket module receives the task flow, it obtains the task information of the task object in the task flow; Step S02: The ticket module generates the task ticket based on the task information.

[0060] It is understandable that when the ticket module receives the task flow, it can obtain the task information of the sub-task objects in the task flow, generate sub-task numbers based on the task information of each sub-task object, and generate corresponding task tickets based on the sub-task numbers. The task to be processed mentioned above can also be a task that requires multiple iterations, or it can be other types of tasks. The method for generating task tickets can be determined according to the actual situation, and this embodiment does not impose any restrictions on it.

[0061] In the specific implementation, when the ticket module receives the task flow, it obtains the task information of the task object in the task flow and generates a task ticket based on the task information.

[0062] Furthermore, to better complete the processing of the task group, after the thread submodule executes the step of performing a ticket-grabbing operation on the ticket module based on exclusive access to obtain the task ticket when the task object is completed, it also includes: Step S101: When the remaining amount of the bill is zero, the bill module queries the process information of the task flow; Step S102: When there are other task flows that depend on the task flow, the ticket module generates a new task ticket based on the task information of the task objects in the other task flows.

[0063] It should be noted that when the remaining number of tickets in the ticket module is zero, it indicates that the current task process has been completed. At this point, the ticket module will query the task process information. If there are other task processes that depend on the current task process, new task tickets can be generated based on these other task processes to improve the execution efficiency of the task group. If there are no other task processes that depend on the current task process, it means that this task request has been completed, and the task processing flow can be terminated.

[0064] In the specific implementation, when the remaining amount of the ticket is zero, the ticket module queries the process information of the task flow; when there are other task flows that depend on the task flow, the ticket module generates a new task ticket based on the task information of the task objects in the other task flows.

[0065] This embodiment creates thread submodules based on idle processing units and varying numbers of task objects. A ticket module generates task tickets corresponding to each task object. The thread submodules then use a ticket-grabbing operation to process each task object. When the remaining ticket quantity is zero, the process information corresponding to the task flow is queried. If the task flow depends on other task flows, new task tickets are generated based on the task information of the task objects in those other task flows. By creating thread submodules and processing task objects through a ticket-grabbing method, the overall performance degradation caused by processing interruptions in certain cores is avoided. The waiting time when thread task objects complete processing is reduced, resulting in more rational utilization of system resources, improved efficiency of multi-task parallel processing, and enhanced overall task performance.

[0066] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or system that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or system. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or system that includes that element.

[0067] The sequence numbers of the above embodiments of the present invention are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0068] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as read-only memory / random access memory, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0069] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A multi-core parallel computing scheduling system, characterized in that, The system is used for parallel processing of multiple tasks, and the system includes: a ticket module and a thread module; the thread module includes at least two thread sub-modules. The thread submodule is used to perform a ticket grabbing operation on the ticket module based on exclusive access when the remaining task tickets in the ticket module are not zero, so as to obtain task tickets. The thread submodule is also used to process the task object corresponding to the task ticket; The thread submodule is also used to perform a ticket grabbing operation on the ticket module based on exclusive access when the task object is completed, and when the remaining task ticket quantity in the ticket module is not zero, so as to obtain the task ticket. The task object is one of the executable objects contained in a task flow; The ticket module is used to obtain the task information of the task object in the task process when the task process is received; The ticket module is also used to generate the task ticket based on the task information.

2. The multi-core parallel computing scheduling system as described in claim 1, characterized in that, The thread module is used to generate a thread sub-module based on the number of task objects corresponding to the task processing request and the number of idle processing units when a task processing request is received.

3. The multi-core parallel computing scheduling system as described in claim 2, characterized in that, The thread module is further configured to generate a thread sub-module with the same number of task objects when the number of task objects is less than or equal to the number of idle processing units; The thread module is further configured to generate a thread sub-module with the same number of idle processing units when the number of task objects is greater than the number of idle processing units.

4. The multi-core parallel computing scheduling system as described in claim 1, characterized in that, The bill module is also used to query the process information of the task flow when the remaining amount of the bill is zero. The ticket module is also used to generate new task tickets based on the task information of the task objects in other task processes when there are other task processes that depend on the task process.

5. A multi-core parallel computing scheduling method, characterized in that, The method is applied to the scheduling system, which includes: a ticket module and a thread module; the thread module includes at least two thread sub-modules; the method includes: When the remaining task tickets in the ticket module are not zero, the thread submodule performs a ticket grabbing operation on the ticket module based on exclusive access in order to obtain task tickets. The thread submodule processes the task object corresponding to the task ticket; When the task object is completed, the thread submodule executes the step of grabbing a ticket from the ticket module based on exclusive access when the remaining task ticket quantity in the ticket module is not zero, so as to obtain the task ticket. The task object is one of the executable objects contained in a task flow; When the bill module receives the task flow, it obtains the task information of the task object in the task flow; The ticket module generates the task ticket based on the task information.

6. The multi-core parallel computing scheduling method as described in claim 5, characterized in that, Before the step of the thread submodule performing a ticket-grabbing operation on the ticket module based on exclusive access to obtain a task ticket when the remaining task tickets in the ticket module are not zero, the following steps are also included: When the thread module receives a task processing request, it generates a thread sub-module based on the number of task objects corresponding to the task processing request and the number of idle processing units.

7. The multi-core parallel computing scheduling method as described in claim 6, characterized in that, When the thread module receives a task processing request, the steps for generating a thread sub-module based on the number of task objects corresponding to the task processing request and the number of idle processing units include: When the number of task objects is less than or equal to the number of idle processing units, the thread module generates a thread sub-module with the same number of task objects. When the number of task objects is greater than the number of idle processing units, the thread module generates a thread sub-module with the same number of idle processing units.

8. The multi-core parallel computing scheduling method as described in claim 5, characterized in that, After the thread submodule executes the step of performing a ticket-grabbing operation on the ticket module based on exclusive access to obtain a task ticket when the task object is processed and the remaining task ticket quantity in the ticket module is not zero, it further includes: When the remaining amount of the invoices is zero, the invoice module queries the process information of the task flow. When there are other task flows that depend on the task flow, the ticket module generates a new task ticket based on the task information of the task objects in the other task flows.

Images