Thread pool implementation method for executing decomposable tasks
By designing the task scheduler and subtask scheduler of thread pool, the problem that existing thread pool methods cannot efficiently execute decomposed tasks is solved, and more efficient concurrent execution and task state management are achieved.
Patent Information
- Application Number
- CN202411866878.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-12-18
- Publication Date
- 2025-04-11
AI Technical Summary
Existing thread pooling methods are not suitable for performing decomposed tasks because they cannot maximize the utilization of concurrency and lose state management of the parent task when executed in sub-tasks.
A thread pool implementation method is designed. By introducing the concepts of decomposed tasks (Task) and subtasks (Jobs), the execution process of task schedulers, Task schedulers, and Job schedulers is designed to realize a thread pool that can execute multiple decomposed tasks.
This method improves concurrency efficiency by managing subtasks of decomposed tasks, and does not destroy the integrity of decomposed tasks when executing subtasks, making it convenient for management and maintenance of the status and queue of decomposed tasks.
Smart Images
Figure CN119806773A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of computer application technology, and in particular to a thread pool implementation method for executing decomposable tasks, which can execute multiple decomposable tasks by constructing a thread pool. Background Art
[0002] In different programming languages and frameworks, thread pool implementation methods are common. The implementation idea is to maintain a certain number of threads and share a task queue. The threads are not destroyed after executing the task, and can repeatedly obtain tasks from the task queue for execution, thereby achieving the purpose of thread resource reuse and improving concurrency efficiency. However, this type of thread pool is for a series of independent executable tasks. In actual business scenarios, there are still a large number of decomposable tasks. Decomposable tasks refer to execution units that can be decomposed into subtasks again. If such tasks are executed using the current thread pool, if they are executed as tasks, the concurrency capability is not maximized. If they are executed as subtasks, the state management of the parent task will be lost. Therefore, the current thread pool method is not suitable for the execution of decomposable tasks.
[0003] Currently, there is no relevant solution on the market. Summary of the invention
[0004] In view of the above technical problems in the related art, the present invention proposes a thread pool implementation method for executing decomposable tasks, which can overcome the above deficiencies in the prior art.
[0005] To achieve the above technical objectives, the technical solution of the present invention is implemented as follows: A thread pool implementation method for executing decomposable tasks comprises the following steps: S1 defines properties: defines the properties required to create a thread pool, including Task, Job, MAX_POOL_SIZE, MAX_Task_SIZE, BLOCK_TIME_OUT, TaskQueue, JobQueue, RunningTaskList, and LastTaskIndex; Task: A decomposable task, including multiple subtasks. The task is considered completed only when all its subtasks are completed. Job: subtask, as the smallest execution unit, is decomposed from Task; MAX_POOL_SIZE: The maximum number of threads in the thread pool; MAX_Task_SIZE: The maximum number of tasks that can be executed simultaneously in the thread pool; BLOCK_TIME_OUT: thread blocking time; TaskQueue: The Task queue waiting to be executed in the thread pool, following the first-in-first-out principle; JobQueue: The job queue waiting to be executed in each Task, following the first-in-first-out principle; RunningTaskList: List array, representing the Task array being executed; LastTaskIndex: The index value of the Task to which a specific Job belongs that was obtained from RunningTaskList the last time in the Task array. The initial value is set to 0. S2 initialization: S2.1: Create the thread pool according to the attributes, initialize the attributes, and set the task scheduler, task scheduler, and job scheduler for auxiliary thread execution; S2.2: Create a number of threads in the thread pool, the number of threads is MAX_POOL_SIZE, put all threads into a thread array and start them; S3 updates the array: whenever a new Task is submitted, it is added to the TaskQueue; S4 execution thread: through the cooperation of task scheduler, task scheduler and job scheduler, it realizes the acquisition of subtask Job and executes the acquired subtask Job; S5 loop execution: After the subtask Job is executed, the loop should be repeated, so return to S3. The task scheduler, Task scheduler, and Job scheduler can be implemented using existing technologies.
[0006] In one embodiment, in S4, the task scheduler obtains the subtask Job in the following steps: S4.1: Start calling the Task scheduler to obtain a Task. If the obtained Task is not Null, jump to S4.3; otherwise, it means that the Task is currently empty, and continue to S4.2; S4.2: Block the thread for BLOCK_TIME_OUT, and return to S4.1 after the blocking ends; S4.3: Call the Job scheduler to obtain a Job from the Task. If Job≠Null, it means that the Job is obtained successfully, and continue to S4.4; otherwise, it means that there is no Job on the current Task, the acquisition fails, and return to S4.2; S4.4: The Job obtained in S4.3 is used as the final result obtained by the task scheduler, that is, the subtask Job obtained, and the operation is terminated.
[0007] Preferably, in S4.1, the steps for the Task scheduler to obtain a Task are as follows: S4.1.1: Determine the number of elements in the RunningTaskList. If the number of its elements is less than MAX_Task_SIZE, proceed to S4.1.2; otherwise, jump to S4.1.3; S4.1.2: Take a Task from the TaskQueue. If the taken Task ≠ Null, add it to the RunningTaskList and return to S4.1.1; otherwise, it means there is no Task in the TaskQueue yet, so proceed to S4.1.3; S4.1.3: Obtain a Task from the RunningTaskList as the acquisition result of the Task scheduler. This acquisition result may be a valid Task or a Null object, and the operation ends.
[0008] Preferably, the steps of S4.1.3 are as follows: S4.1.3.1: Set a temporary task TempTask and an integer variable i, and set the initial value of i to 0; S4.1.3.2: Calculate index = (i + LastTaskIndex + 1) % MAX_Task_SIZE; S4.1.3.3: Obtain the element with the index of index from the RunningTaskList and assign it to the TempTask, that is, TempTask = RunningTaskList[index]; S4.1.3.4: If TempTask ≠ Null, set LastTaskIndex = index and directly jump to S4.1.3.6; otherwise, increment the value of i and then proceed to S4.1.3.5; S4.1.3.5: If i < MAX_Task_SIZE, return to S4.1.3.2; otherwise, it means that the RunningTaskList has been traversed and no valuable task has been obtained yet, so the iteration should end. Therefore, set TempTask = Null; S4.1.3.6: Assign TempTask to Task and use Task as the acquisition result of the Task scheduler, and the operation ends.
[0009] Preferably, in S4.3, the steps for the Job scheduler to obtain a Job are as follows: S4.3.1: Take a Job from the JobQueue of the Task; S4.3.2: If the Job retrieved in S4.3.1 ≠ Null, it means the retrieval is successful, so continue to S4.3.3; otherwise, it means the retrieval fails and the JobQueue of the Task is empty, so jump to S4.3.4; S4.3.3: Determine the number of elements in the JobQueue. If the number of elements is 0, it means that the JobQueue of the Task is empty and the Task should be removed, so continue with S4.3.4; otherwise, it means that the JobQueue of the Task is not empty yet and the Task cannot be removed, so jump directly to S4.3.5; S4.3.4: Remove the Task from RunningTaskList and continue with S4.3.5; S4.3.5: Use job as the acquisition result of the Job scheduler and end the operation.
[0010] Preferably, the value range of MAX_POOL_SIZE is preferably 5--30, unit / piece.
[0011] Preferably, the value range of MAX_Task_SIZE is preferably 5--30, unit / task.
[0012] Preferably, the value range of BLOCK_TIME_OUT is 1--20, unit: / s.
[0013] Preferably, the value range of BLOCK_TIME_OUT is 100--1000, unit: / ms.
[0014] Beneficial effects of the present disclosure: The present disclosure introduces the concepts of decomposable tasks and subtasks, and designs task queues and task schedulers based on them, thereby realizing a thread pool that can execute multiple decomposable tasks, fully reusing thread resources, and improving the efficiency of concurrent execution of tasks.
[0015] This method introduces the concepts of decomposable tasks and subtasks, designs the execution process of task scheduler, task scheduler, and job scheduler, and implements a thread pool that can execute multiple decomposable tasks. It has the following effects: (A) The subtasks of the decomposable tasks are managed by the task scheduler and executed by the thread pool, thereby improving the concurrency efficiency; (B) The threads execute subtasks but do not destroy the integrity of the decomposable tasks, which facilitates the management and maintenance of the status and queue of the decomposable tasks. BRIEF DESCRIPTION OF THE DRAWINGS
[0016] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0017] Figure 1 This is a schematic diagram of thread execution in the thread pool implementation method described in the present disclosure.
[0018] Figure 2 The present invention is a flowchart of a task scheduler in the thread pool implementation method described in the present invention.
[0019] Figure 3 The present invention is a flowchart of the Task scheduler in the thread pool implementation method described in the present invention.
[0020] Figure 4 The present invention is a flowchart of obtaining a Task from a RanningTaskList in the thread pool implementation method described in the present invention.
[0021] Figure 5 The present invention is a flowchart of the Job scheduler in the thread pool implementation method described in the present invention. DETAILED DESCRIPTION
[0022] The technical solutions in the embodiments of the present invention will be described clearly and completely below in conjunction with the accompanying drawings in the embodiments of the present invention.
[0023] like Figure 1-5 As shown, in order to facilitate understanding of the above technical solutions of the present invention, the above technical solutions of the present invention are described in detail below through specific usage methods.
[0024] The thread pool implementation method comprises the following steps: S1 defines properties: defines the properties required to create a thread pool, including Task, Job, MAX_POOL_SIZE, MAX_Task_SIZE, BLOCK_TIME_OUT, TaskQueue, JobQueue, RunningTaskList, and LastTaskIndex; Task: A decomposable task, including multiple subtasks. The task is considered completed only when all its subtasks are completed. Job: subtask, as the smallest execution unit, is decomposed from Task; MAX_POOL_SIZE: The maximum number of threads in the thread pool; MAX_Task_SIZE: The maximum number of tasks that can be executed simultaneously in the thread pool; BLOCK_TIME_OUT: thread blocking time; TaskQueue: The Task queue waiting to be executed in the thread pool, following the first-in-first-out principle; JobQueue: The job queue waiting to be executed in each Task, following the first-in-first-out principle; RunningTaskList: List array, representing the Task array being executed; LastTaskIndex: The index value of the Task to which a specific Job belongs that was obtained from RunningTaskList the last time in the Task array. The initial value is set to 0. S2 initialization: S2.1: Create the thread pool according to the attributes, initialize the attributes, and set the task scheduler, task scheduler, and job scheduler for auxiliary thread execution; S2.2: Create a number of threads in the thread pool, the number of threads is MAX_POOL_SIZE, put all threads into a thread array and start them; S3 updates the array: whenever a new Task is submitted, it is added to the TaskQueue; S4 execution thread: through the cooperation of task scheduler, task scheduler and job scheduler, it realizes the acquisition of subtask Job and executes the acquired subtask Job; S5 loop execution: After the subtask Job is executed, the loop should be repeated, so return to S3.
[0025] In one embodiment, in S4, the task scheduler obtains the subtask Job in the following steps: S4.1: Start calling the Task scheduler to obtain a Task. If the obtained Task is not Null, jump to S4.3; otherwise, it means that the Task is currently empty, and continue to S4.2; S4.2: Block the thread for BLOCK_TIME_OUT, and return to S4.1 after the blocking ends; S4.3: Call the Job scheduler to obtain a Job from the Task. If Job≠Null, it means that the Job is obtained successfully, and continue to S4.4; otherwise, it means that there is no Job on the current Task, the acquisition fails, and return to S4.2; S4.4: Use the Job obtained in S4.3 as the final result obtained by the task scheduler, that is, the obtained subtask Job, and end the operation.
[0026] In a certain embodiment, in S4.1, the steps for the Task scheduler to obtain a Task are as follows: S4.1.1: Determine the number of elements in the RunningTaskList. If the number of its elements is less than MAX_Task_SIZE, then continue with S4.1.2; otherwise, jump to S4.1.3; S4.1.2: Take a Task from the TaskQueue. If the taken Task ≠ Null, then add it to the RunningTaskList and return to S4.1.1; otherwise, it means that there is no Task in the TaskQueue yet, so continue with S4.1.3; S4.1.3: Obtain a Task from the RunningTaskList as the obtained result of the Task scheduler. This obtained result may be a valid Task or a Null object, and end the operation.
[0027] In a certain embodiment, the steps of S4.1.3 are as follows: S4.1.3.1: Set a temporary task TempTask and an integer variable i, and set the initial value of i to 0; S4.1.3.2: Calculate index = (i + LastTaskIndex + 1) % MAX_Task_SIZE; S4.1.3.3: Obtain the element with the index of index from the RunningTaskList and assign it to the TempTask, that is, TempTask = RunningTaskList[index]; S4.1.3.4: If TempTask ≠ Null, then set LastTaskIndex = index and directly jump to S4.1.3.6; otherwise, increment the value of i by 1, and then continue with S4.1.3.5; S4.1.3.5: If i < MAX_Task_SIZE, then return to S4.1.3.2; otherwise, it means that the RunningTaskList has been traversed to the end and no valuable task has been obtained, so the iteration should be ended, and thus set TempTask = Null; S4.1.3.6: Assign TempTask to Task, and use Task as the obtained result of the Task scheduler, and end the operation.
[0028] In one embodiment, in S4.3, the steps of the Job scheduler obtaining the Job are as follows: S4.3.1: Take a Job from the Task's JobQueue; S4.3.2: If the Job retrieved in S4.3.1 ≠ Null, it means the retrieval is successful, so continue to S4.3.3; otherwise, it means the retrieval fails and the JobQueue of the Task is empty, so jump to S4.3.4; S4.3.3: Determine the number of elements in the JobQueue. If the number of elements is 0, it means that the JobQueue of the Task is empty and the Task should be removed, so continue with S4.3.4; otherwise, it means that the JobQueue of the Task is not empty yet and the Task cannot be removed, so jump directly to S4.3.5; S4.3.4: Remove the Task from RunningTaskList and continue with S4.3.5; S4.3.5: Use job as the acquisition result of the Job scheduler and end the operation.
[0029] In a certain embodiment, the value range of MAX_POOL_SIZE is preferably 5--30, unit / piece.
[0030] In a certain embodiment, the value range of MAX_Task_SIZE is preferably 5--30, unit / task.
[0031] In a certain embodiment, the value range of BLOCK_TIME_OUT is preferably 1--20, unit / s.
[0032] In a certain embodiment, the value range of BLOCK_TIME_OUT is preferably 100--1000, unit: / ms.
[0033] In summary, through the above unique technical solution, this method introduces the concepts of decomposable tasks (Task) and subtasks (Job), designs the execution process of task scheduler, Task scheduler, and Job scheduler, and realizes a thread pool that can execute multiple decomposable tasks, which has the following effects: (A). The subtasks of the decomposable task are managed by the task scheduler and executed by the thread pool, thereby improving the concurrency efficiency; (B). The thread executes the subtask, but does not destroy the integrity of the decomposable task, which facilitates the management and maintenance of the status and queue of the decomposable task.
[0034] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims
1. A thread pool implementation method for executing decomposable tasks, characterized in that: The following steps are involved: S1 defines properties: defines the properties required to create a thread pool, including Task, Job, MAX_POOL_SIZE, MAX_Task_SIZE, BLOCK_TIME_OUT, TaskQueue, JobQueue, RunningTaskList, and LastTaskIndex; Task: A decomposable task, including multiple subtasks. The task is considered completed only when all its subtasks are completed. Job: subtask, as the smallest execution unit, is decomposed from Task; MAX_POOL_SIZE: The maximum number of threads in the thread pool; MAX_Task_SIZE: The maximum number of tasks that can be executed simultaneously in the thread pool; BLOCK_TIME_OUT: thread blocking time; TaskQueue: The Task queue waiting to be executed in the thread pool, following the first-in-first-out principle; JobQueue: The job queue waiting to be executed in each Task, following the first-in-first-out principle; RunningTaskList: List array, representing the Task array being executed; LastTaskIndex: The index value of the Task to which a specific Job belongs that was obtained from RunningTaskList the last time in the Task array. The initial value is set to 0. S2 initialization: S2.1: Create the thread pool according to the attributes, initialize the attributes, and set the task scheduler, task scheduler, and job scheduler for auxiliary thread execution; S2.2: Create a number of threads in the thread pool, the number of threads is MAX_POOL_SIZE, put all threads into a thread array and start them; S3 updates the array: whenever a new Task is submitted, it is added to the TaskQueue; S4 execution thread: through the cooperation of task scheduler, task scheduler and job scheduler, it realizes the acquisition of subtask Job and executes the acquired subtask Job; S5 loop execution: After the subtask Job is executed, the loop should be repeated, so return to S3.
2. The thread pool implementation method according to claim 1, characterized in that: In S4, the task scheduler obtains the subtask Job in the following steps: S4.1: Start calling the Task scheduler to obtain a Task. If the obtained Task is not Null, jump to S4.3; otherwise, it means that the Task is currently empty, and continue to S4.2; S4.2: Block the thread for BLOCK_TIME_OUT, and return to S4.1 after the blocking ends; S4.3: Call the Job scheduler to obtain a Job from the Task. If Job≠Null, it means that the Job is obtained successfully, and continue to S4.4; Otherwise, it means that there is no Job on the current Task and the acquisition fails, so the process returns to S4.2; S4.4: Use the Job obtained in S4.3 as the final result obtained by the task scheduler - that is, the obtained sub-task Job, and end the operation.
3. The thread pool implementation method according to claim 2, characterized in that: In S4.1, the steps for the Task scheduler to obtain a Task are as follows: S4.1.1: Judge the number of elements in the RunningTaskList. If the number of its elements is less than MAX_Task_SIZE, then continue with S4.1.2; otherwise, jump to S4.1.3; S4.1.2: Take out a Task from the TaskQueue. If the taken-out Task ≠ Null, then add it to the RunningTaskList and return to S4.1.1; Otherwise, it means that there is no Task in the TaskQueue yet, so continue with S4.1.3; S4.1.3: Take out a Task from the RunningTaskList as the obtained result of the Task scheduler. This obtained result may be a valid Task or a Null object, and end the operation.
4. The thread pool implementation method according to claim 3, characterized in that: The steps of S4.1.3 are as follows: S4.1.3.1: Set a temporary task TempTask and an integer variable i, and set the initial value of i to 0; S4.1.3.2: Calculate index = (i + LastTaskIndex + 1) % MAX_Task_SIZE; S4.1.3.3: Take out the element with the index of index from the RunningTaskList and assign it to the TempTask, that is, TempTask = RunningTaskList[index]; S4.1.3.4: If TempTask ≠ Null, then set LastTaskIndex = index and directly jump to S4.1.3.6; otherwise, increment the value of i by 1 and then continue with S4.1.3.5; S4.1.3.5: If i < MAX_Task_SIZE, then return to S4.1.3.2; otherwise, it means that the RunningTaskList has been traversed and no valuable task has been obtained yet, so the iteration should be ended. Therefore, set TempTask = Null; S4.1.3.6: Assign TempTask to Task and use Task as the obtained result of the Task scheduler, and end the operation.
5. The thread pool implementation method according to claim 2, characterized in that: In S4.3, the steps for the Job scheduler to obtain a Job are as follows: S4.3.1: Take out a Job from the JobQueue of the Task; S4.3.2: If the Job taken out in S4.3.1 ≠ Null, it means that the acquisition is successful, so continue with S4.3.3; otherwise, it means that the acquisition fails and the JobQueue of the Task is empty, and jump to S4.3.4; S4.3.3: Judge the number of elements in the JobQueue. If the number of elements is 0, it means that the JobQueue of the Task is empty and the Task should be removed, so continue with S4.3.4; Otherwise, it means that the JobQueue of the Task is not empty yet and the Task cannot be removed, so jump directly to S4.3.5; S4.3.4: Remove the Task from RunningTaskList and continue with S4.3.5; S4.3.5: Use job as the acquisition result of the Job scheduler and end the operation.
6. The thread pool implementation method according to claim 1, characterized in that: The value range of MAX_POOL_SIZE is preferably 5--30, unit / piece.
7. The thread pool implementation method according to claim 1, characterized in that: The value range of MAX_Task_SIZE is preferably 5--30, unit / task.
8. The thread pool implementation method according to claim 1, characterized in that: The value range of BLOCK_TIME_OUT is preferably 1--20, unit: / s.
9. The thread pool implementation method according to claim 1, characterized in that: The value range of BLOCK_TIME_OUT is preferably 100--1000, unit: / ms.