Thread compatible scheduling method, multi-language mixing system, device and related equipment

Abstract

The invention provides a thread compatible scheduling method, a multi-language mixing system, a multi-language mixing device and related equipment, and relates to the technical field of computer control. According to the method, tasks are uniformly submitted to a central scheduling unit through a language adaptation unit; the central scheduling unit periodically receives and maintains the thread resource state of each heterogeneous language module; the central scheduling unit performs scheduling decision making according to thread resource states, including preferentially scheduling to an initiation language module, scheduling to other sufficient modules supporting the function when resources are insufficient, or adding tasks into a waiting queue; after the task is distributed to the target module, the language adaptation unit creates a thread and binds a task context to execute the task; and after the task is completed, an execution result is reported to the central scheduling unit. The method aims at solving the problems that in the prior art, thread scheduling splitting, resource conflicts, context breakage and the like cannot be solved in the multi-language environment, and the performance, stability and maintainability of a high-concurrency system can be improved.

Description

Technical Field

[0001] The present invention relates to the field of computer control technology, and in particular to a thread-compatible scheduling method, a multi-language hybrid system, a device and related equipment. Background Art

[0002] With the rapid development of artificial intelligence and large language models, multi-language hybrid development has become a mainstream trend in distributed systems and enterprise-level software architectures. Specifically, systems use multiple languages ​​to implement different functional modules. For example, Java is used to build the main business logic, interface services, and task scheduling modules; Python is used for AI reasoning, data analysis, image processing, etc.; and C / C++ is used for performance-critical components such as image encoding and decoding, low-level drivers, encryption and decryption.

[0003] Each language typically runs in its own independent runtime environment (e.g. Java, Python, C / C++ in JVM, CPython, Native Thread respectively), and is equipped with its own thread pool or task execution model. For example: Java runs on the JVM (Java Virtual Machine). Common concurrency models include ThreadPoolExecutor and ForkJoinPool, which are widely used in multi-threaded task scheduling and parallel computing. Python typically runs in the CPython interpreter and supports multiple concurrency mechanisms. For example, the thread-based ThreadPoolExecutor is suitable for I / O-intensive tasks, the process-based ProcessPoolExecutor can bypass the Global Interpreter Lock (GIL) to handle CPU-intensive tasks, and the event loop-based asyncio coroutine model is provided for high-concurrency asynchronous I / O scenarios. C++ is compiled into native machine code and runs in the native thread environment provided by the operating system. Common concurrency models include std::thread in the standard library, thread pool implementations, and third-party libraries such as Boost.Thread, which can achieve high-performance multi-threaded concurrency control.

[0004] In this multi-language hybrid architecture, existing systems have the following problems in concurrent task scheduling and thread resource usage: 1. Each language thread pool is scheduled independently and lacks coordination: Each language module is unaware of each other's use of thread pool resources, and multiple large thread pools may be started on the same operating system, resulting in excessive resource consumption and frequent thread context switching, causing continuously high CPU load, system lag or thread starvation, lack of a global thread scheduling strategy, and chaotic thread priority management.

[0005] 2. Inconsistent task scheduling: Currently, thread scheduling decisions are limited to each language module, making cross-language coordination difficult. For example, while a Java module is executing a high-priority task, a Python module might simultaneously initiate a low-priority request, causing important tasks to preempt resources and making task response times uncontrollable.

[0006] 3. Context is lost and thread ownership is difficult to maintain: In cross-language call chains (such as Java calling Python, and Python calling C++), since the runtime context between languages ​​is not shared, problems such as log link interruption, request tracing failure, and loss of user identity information and call parameters often occur. At the same time, the lack of a unified context transfer mechanism makes it difficult to meet audit and security requirements.

[0007] 4. Unable to uniformly collect task status and thread health indicators: Multi-language thread pools run independently, making debugging and monitoring very difficult. Especially in large-scale deployment scenarios, the lack of unified task status query and thread health monitoring methods increases the complexity of system maintenance.

[0008] In summary, existing technologies cannot solve problems such as thread scheduling splitting, resource conflicts, and context breaks in multi-language environments, which restricts the performance, stability, and maintainability of high-concurrency systems.

[0009] There is currently no effective technical solution to the above problems. Summary of the Invention

[0010] The purpose of the present invention is to provide a thread-compatible scheduling method, a multi-language hybrid system, an apparatus and related equipment thereof, aiming to solve the problems of thread scheduling splitting, resource conflicts, context breaks, etc. in a multi-language environment that cannot be solved by existing technologies, and is conducive to improving the performance, stability and maintainability of high-concurrency systems.

[0011] In a first aspect, the present invention provides a thread-compatible scheduling method, which is applied to a multi-language hybrid system. The multi-language hybrid system includes a plurality of heterogeneous language modules and a central scheduling unit, and each of the heterogeneous language modules is deployed with a corresponding language adaptation unit. The thread compatible scheduling method comprises the following steps: After a task is created locally, the language adaptation unit in the heterogeneous language module corresponding to the initiating language used by the task is controlled to construct a task request data structure for the task, and submit the task request data structure to the central scheduling unit; the task request data structure includes context information of the corresponding task; Controlling the central scheduling unit to periodically receive and maintain thread resource status information from each of the heterogeneous language modules; After the central scheduling unit receives the task, controlling the central scheduling unit to make a scheduling decision for the task and determine a target heterogeneous language module according to the task request data structure and the thread resource status information of the task; Distributing the task to a language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined after the task scheduling decision; After the target heterogeneous language module receives the task, the target heterogeneous language module is controlled to create an execution thread, and the context information of the task is bound to the life cycle of the execution thread, and the task is executed through the execution thread; After the task is completed, the language adaptation unit in the target heterogeneous language module is controlled to report the execution result of the task to the central scheduling unit.

[0012] The thread-compatible scheduling method of the present invention, by introducing the "central scheduling unit + language adaptation unit" architecture, realizes the unified registration, scheduling decision, thread allocation and context maintenance of heterogeneous language tasks, which is beneficial to improving the performance, stability and maintainability of high-concurrency systems.

[0013] Furthermore, the task request data structure also includes a function identifier, an initiating language, a priority, and an estimated resource usage of the corresponding task.

[0014] Furthermore, the thread resource status information includes the number of active threads, the maximum capacity of the thread pool, and the current resource occupancy.

[0015] Furthermore, after the central scheduling unit receives the task, the step of controlling the central scheduling unit to make a scheduling decision for the task based on the task request data structure and the thread resource status information, and determining the target heterogeneous language module includes: After the central scheduling unit receives the task, it controls the central scheduling unit to make a scheduling decision for the task and determine a target heterogeneous language module according to the function identifier, initiating language, priority, estimated resource occupancy and thread resource status information of the task.

[0016] Furthermore, after the central scheduling unit receives the task, the step of controlling the central scheduling unit to make a scheduling decision for the task based on the function identifier, initiating language, priority, estimated resource usage, and thread resource status information of the task, and determining the target heterogeneous language module includes: A1. If the thread resources of the heterogeneous language module corresponding to the initiating language are greater than or equal to the estimated resource usage of the task, the heterogeneous language module corresponding to the initiating language is deemed to have sufficient resources and is determined as the target heterogeneous language module. A2. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task does not indicate that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is deemed to be resource-constrained. Based on the thread resource status information, another heterogeneous language module whose thread resources are greater than or equal to the estimated resource usage of the task is selected and determined as the target heterogeneous language module. A3. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task indicates that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module, so that in a subsequent distribution step, the task is added to the waiting queue of the target heterogeneous language module according to the priority of the task, and is thereby executed sequentially according to the waiting queue.

[0017] This effectively avoids the problem of excessive load on a single heterogeneous language module due to task concentration or insufficient resources, significantly enhancing the stability and reliability of the multi-language hybrid system. It also ensures orderly execution under resource constraints, further improving the system's fault tolerance and business continuity.

[0018] Furthermore, after the life cycle of the execution thread ends, the context information of the corresponding task bound to the execution thread is automatically destroyed.

[0019] In a second aspect, the present invention provides a multi-language hybrid system, comprising a plurality of heterogeneous language modules and a central scheduling unit, wherein each of the heterogeneous language modules is deployed with a corresponding language adaptation unit; The heterogeneous language module is used to perform the following steps: After a task is created locally, the corresponding language adaptation unit is controlled according to the initiating language used by the task to construct a task request data structure for the task and submit the task request data structure to the central scheduling unit; the task request data structure includes context information of the corresponding task; The central dispatching unit is configured to perform the following steps: Periodically receiving and maintaining thread resource status information from each of the heterogeneous language modules; After receiving the task, a scheduling decision is made for the task based on the task request data structure and the thread resource status information of the task, and a target heterogeneous language module is determined; Distributing the task to a language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined after the task scheduling decision; The heterogeneous language module is further configured to perform the following steps: After receiving the task, an execution thread is created, and the context information of the task is bound to the life cycle of the execution thread, and the task is executed through the execution thread; After the task is completed, the corresponding language adaptation unit is controlled to report the execution result of the task to the central scheduling unit.

[0020] The multilingual hybrid system of this invention effectively avoids excessive resource consumption and thread starvation, optimizes the efficiency of thread context switching, and ensures timely response to high-priority tasks. Furthermore, it ensures data consistency and traceability, significantly improving system stability, maintainability, and overall performance.

[0021] In a third aspect, the present invention provides a thread-compatible scheduling device, which is applied to a multi-language hybrid system. The multi-language hybrid system includes a plurality of heterogeneous language modules and a central scheduling unit, and each of the heterogeneous language modules is deployed with a corresponding language adaptation unit. The thread-compatible scheduling device includes: a construction module configured to, after a task is created locally, control the language adaptation unit in the heterogeneous language module corresponding to the initiating language used by the task, construct a task request data structure for the task, and submit the task request data structure to the central scheduling unit; the task request data structure includes context information of the corresponding task; a receiving and maintaining module, configured to control the central scheduling unit to periodically receive and maintain thread resource status information from each of the heterogeneous language modules; a decision module, configured to control the central scheduling unit to make a scheduling decision for the task and determine a target heterogeneous language module based on the task request data structure and the thread resource status information of the task after the central scheduling unit receives the task; a distribution module, configured to distribute the task to a language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined after the task scheduling decision; a control execution module, configured to control the target heterogeneous language module to create an execution thread after the target heterogeneous language module receives the task, bind the context information of the task to the life cycle of the execution thread, and execute the task through the execution thread; The reporting module is used to control the language adaptation unit in the target heterogeneous language module to report the execution result of the task to the central scheduling unit after the task is completed.

[0022] Compared with the existing technology, which has the disadvantages of independent scheduling of each language module, lack of mutual resource awareness, and easy loss of context, the thread-compatible scheduling device of the present invention achieves a global view and unified scheduling of thread resources in a multi-language hybrid system by introducing a central scheduling unit.

[0023] In a fourth aspect, the present invention provides an electronic device comprising a processor and a memory, wherein the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the steps of the thread-compatible scheduling method provided in the first aspect are executed.

[0024] In a fifth aspect, the present invention provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the thread-compatible scheduling method provided in the first aspect are executed.

[0025] As can be seen from the above, the thread-compatible scheduling method provided by the present invention has the following advantages: 1. Unified scheduling strategy: Implement centralized scheduling of multi-language module tasks, solve the problem of thread explosion, and improve resource utilization; 2. Complete context transfer: Maintains the complete task call chain and supports log auditing, link tracking, security control, etc. 3. Task priority consistency: High-priority tasks will not have their resources preempted due to language boundaries, ensuring the stability of key processes; 4. Cross-language thread ownership awareness: This enables thread management to no longer be limited to a specific language, facilitating thread isolation, circuit breaking, and current limiting. 5. Universality and scalability: Any language module can be connected, and only language adaptation is required.

[0026] Other features and advantages of the present invention will be described in the following description, and in part will become apparent from the description, or will be understood by practicing the embodiments of the present invention. The purposes and other advantages of the present invention can be realized and obtained by the structures particularly pointed out in the written description and the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 A flowchart of a thread-compatible scheduling method provided by an embodiment of the present invention.

[0028] Figure 2 A schematic diagram of the structure of a multi-language hybrid system provided by an embodiment of the present invention.

[0029] Figure 3 A structural diagram of a thread-compatible scheduling device provided by an embodiment of the present invention.

[0030] Figure 4 A schematic structural diagram of an electronic device provided by an embodiment of the present invention.

[0031] Description of labels: 100. Heterogeneous language module; 200. Central dispatch unit; 300. Construction module; 400. Receiving and maintenance module; 500. Decision module; 600. Distribution module; 700. Control execution module; 800. Reporting module; 13. Electronic device; 1301. Processor; 1302. Memory; 1303. Communication bus. DETAILED DESCRIPTION

[0032] The technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only a part of the embodiments of the present invention, not all of the embodiments. The components of the embodiments of the present invention generally described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the claimed invention, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of the present invention.

[0033] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of the present invention, the terms "first", "second", etc. are used only to distinguish the description and should not be understood as indicating or implying relative importance.

[0034] Reference Attachment Figure 1 The present invention provides a thread-compatible scheduling method, which is applied to a multi-language hybrid system. The multi-language hybrid system includes multiple heterogeneous language modules (such as Java heterogeneous language modules, Python heterogeneous language modules, and C++ heterogeneous language modules) and a central scheduling unit. Each heterogeneous language module is deployed with a corresponding language adaptation unit (the language adaptation unit can communicate with the central scheduling unit using HTTP or gRPC). The thread-compatible scheduling method includes the following steps: After a task is created locally, the language adapter unit in the heterogeneous language module corresponding to the initiating language is controlled according to the initiating language used by the task to construct a task request data structure for the task and submit the task request data structure to the central scheduling unit; the task request data structure includes the context information of the corresponding task; Controlling the central scheduling unit to periodically receive and maintain thread resource status information from various heterogeneous language modules; After receiving the task, the central scheduling unit is controlled to make a scheduling decision for the task based on the task request data structure and thread resource status information of the task, and determine the target heterogeneous language module; Distributing the task to the language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined after the task scheduling decision; After receiving the task, the target heterogeneous language module is controlled to create an execution thread and bind the task context information to the life cycle of the execution thread, so that the task can obtain the current context information at any time during the thread running period, achieving data consistency across languages, and executing the task through the execution thread at the same time; After the task is completed, the language adaptation unit in the target heterogeneous language module is controlled to report the execution result of the task to the central scheduling unit.

[0035] Specifically, after a task is created, it is first encapsulated into a task request data structure in the local heterogeneous language module through the language adaptation unit. This data structure carries basic task information and important contextual information, such as the task's unique identifier, initiator information, and any data that needs to remain consistent during task execution. This task request data structure is then submitted to the central scheduling unit as the basis for subsequent scheduling decisions.

[0036] At the same time, the central dispatch unit continuously collects and updates current thread resource status information from each heterogeneous language module. This information may include, but is not limited to, each module's thread pool usage, the number of idle threads, and potential resource bottlenecks. This real-time status information is crucial for the central dispatch unit to make efficient and reasonable scheduling decisions.

[0037] When the central dispatch unit receives a task request, it comprehensively analyzes the task characteristics (such as the initiating language) contained in the task request data structure, as well as the thread resource status information of each heterogeneous language module. Based on this information, the central dispatch unit makes scheduling decisions to determine the most suitable target heterogeneous language module for executing the task. For example, it can prioritize the module based on the task's initiating language, or consider other compatible modules when resources are limited.

[0038] Once the target heterogeneous language module is determined, the task will be distributed to the language adaptation unit of the module. After the target heterogeneous language module receives the task, a new execution thread will be created for it. A key step is to bind the task's context information (such as user ID, task request ID, transaction information, etc.) to the lifecycle of the execution thread (for example, using Java's ThreadLocal, Python's ContextVar, etc. to save the incoming information). This means that throughout the execution of the task, regardless of the language environment in which it runs, its original context information can be accessed at any time, thus ensuring the consistency of cross-language data transfer. Subsequently, the task is actually executed through the created execution thread.

[0039] After a task is completed, the language adaptation unit in the target heterogeneous language module collects the task execution results and reports them to the central scheduling unit. The central scheduling unit can update the task status and record these results in the system log or database, forming a complete task lifecycle management closed loop and enabling cross-language link tracking.

[0040] Compared to the drawbacks of the prior art, where each language module is independently scheduled, resources are not aware of each other, and context is easily lost, the solution of this application achieves a global view and unified scheduling of thread resources in a multi-language hybrid system by introducing a central scheduling unit. This centralized scheduling strategy can effectively avoid excessive resource consumption and thread starvation, optimize the efficiency of thread context switching, and ensure timely response to high-priority tasks. In addition, by binding task context information to the life cycle of the executing thread, the problem of context loss in the cross-language call chain is solved, data consistency and traceability are guaranteed, and the stability, maintainability and overall performance of the system are significantly improved.

[0041] In some embodiments, the task request data structure further includes a task request ID, a function identifier, an initiating language, a priority, an estimated resource usage (eg, CPU or memory usage), and a callback address of context information corresponding to the task.

[0042] In some embodiments, thread resource status information includes the number of active threads, the maximum thread pool capacity, the task queue length, current CPU and memory usage, GIL lock status (only for Python heterogeneous language modules), runtime health indicators (such as the JVM's GC activity rate), and current resource usage. Thread resource status information is typically managed and maintained in the central scheduling unit as a thread resource status table.

[0043] In some embodiments, after the central scheduling unit receives the task, the steps of controlling the central scheduling unit to make a scheduling decision for the task based on the task request data structure and thread resource status information of the task and determining the target heterogeneous language module include: After receiving the task, the central scheduling unit is controlled to make a scheduling decision for the task based on the function identifier, initiating language, priority, estimated resource usage, and thread resource status information of the task, and determine the target heterogeneous language module.

[0044] Furthermore, after the central scheduling unit receives the task, the step of controlling the central scheduling unit to make a scheduling decision for the task based on the function identifier, initiating language, priority, estimated resource usage, and thread resource status information of the task, and determining the target heterogeneous language module includes: A1. If the thread resources of the heterogeneous language module corresponding to the initiating language are greater than or equal to the estimated resource usage of the task, the heterogeneous language module corresponding to the initiating language is deemed to have sufficient resources and is determined as the target heterogeneous language module. A2. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task does not indicate that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is deemed to be resource-constrained. Based on the thread resource status information, another heterogeneous language module with thread resources greater than or equal to the estimated resource usage of the task is selected and determined as the target heterogeneous language module. This allows for alternative scheduling of equivalent functions, reduces the frequency of task dispatches for a single heterogeneous language module, and prevents the concentration of high-overhead tasks on a single heterogeneous language module, thereby reducing the overload on a single heterogeneous language module and ensuring overall system stability. A3. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task indicates that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module. In a subsequent dispatch step, the task is added to the waiting queue of the target heterogeneous language module according to its priority, and is thereby executed sequentially according to the waiting queue.

[0045] Specifically, in step A1, if the current thread resources of the heterogeneous language module corresponding to the task's initiating language (e.g., a comprehensive assessment of the number of active threads, maximum thread pool capacity, and current resource usage) meet the task's estimated resource usage, this indicates that the module is capable of processing the task immediately. Therefore, the task is directly dispatched to the heterogeneous language module corresponding to its initiating language for execution, maintaining task processing locality and efficiency.

[0046] In step A2, when the thread resources of the heterogeneous language module corresponding to the initiating language of the task are insufficient to meet the estimated resource usage of the task, in order to avoid overloading the module, the central scheduling unit will search for other heterogeneous language modules with sufficient thread resources and capable of executing the task based on the collected thread resource status information of each heterogeneous language module. Among them, "equivalent function alternative scheduling" means that if the function of a task can be implemented by multiple languages ​​or modules, then when the resources of the heterogeneous language module of its original initiating language are tight, it can be scheduled to execute on other heterogeneous language modules with equivalent functions, thereby achieving load balancing. For example, modules such as image recognition and data cleaning are implemented in both Java and Python, so these tasks can be dispatched to the Java heterogeneous language module for execution, or to the Python heterogeneous language module for execution. At this time, the Java heterogeneous language module and the Python heterogeneous language module have equivalent functions for the task, so alternative scheduling can be performed based on the resource status of the two to achieve efficient completion of the task.

[0047] In step A3, there is a special case, that is, although the resources of the heterogeneous language module corresponding to the initiating language are tight, the function identifier of the task clearly indicates that it can only be executed by this specific heterogeneous language module (for example, functionType only supports execution in the Java heterogeneous language module, and the current thread pool of the Java heterogeneous language module is busy, then the task enters the waiting queue of the Java heterogeneous language module). In this case, in order to ensure the final execution of the task, the task will still be scheduled to the heterogeneous language module corresponding to its initiating language. At this time, the task will not be executed immediately, but will be added to the waiting queue of the target heterogeneous language module according to its priority, and will be processed in sequence after the resources are released.

[0048] The solution of this application effectively addresses the resource imbalance and overload issues that can arise among heterogeneous language modules in a multilingual hybrid system by introducing refined scheduling decision-making logic. Specifically, when a task is created and submitted to the central scheduling unit, it comprehensively considers the task's characteristics (such as function identifier and estimated resource usage) as well as the real-time thread resource status information of each heterogeneous language module. First, through step A1, tasks can be quickly and directly scheduled for heterogeneous language modules with sufficient resources, ensuring efficient local processing. Second, through step A2, when the heterogeneous language module corresponding to the initiating language is resource-constrained, the system intelligently schedules equivalent functions as replacements. This means that if other heterogeneous language modules have the ability to perform the same or equivalent functions and have sufficient resources, the task will be distributed to these replacement modules. This mechanism effectively reduces the frequency of task dispatches to individual heterogeneous language modules, avoids the concentration of high-overhead tasks on a single module, and significantly reduces the load on specific modules. This prevents system performance degradation or crashes caused by local overload, thereby ensuring overall system stability and resilience. Finally, through step A3, the system ensures that tasks with strong module dependencies, which cannot be rescheduled, are ultimately processed, even if the heterogeneous language module corresponding to their initiating language is resource-constrained. By adding these tasks to the waiting queue of the target heterogeneous language module and executing them sequentially according to priority, the reliability of critical tasks is guaranteed, avoiding task loss or prolonged blocking due to temporary resource shortages, thereby maintaining the integrity of system functionality.

[0049] Through the above technical solution, this application can achieve more intelligent and robust thread-compatible scheduling. Specifically, this solution not only optimizes the scheduling path of tasks and improves resource utilization, but more importantly, it effectively avoids the problem of excessive load of a single heterogeneous language module due to task concentration or insufficient resources by introducing an equivalent function replacement scheduling mechanism, significantly enhancing the stability and reliability of the multi-language hybrid system. At the same time, for tasks with specific module dependencies, priority queue management is used to ensure their orderly execution under resource-constrained conditions, further improving the system's fault tolerance and business continuity.

[0050] In some embodiments, after the lifecycle of the execution thread ends, the context information of the corresponding task bound to the execution thread is automatically destroyed.

[0051] This means that once an execution thread completes its task and ends its lifecycle (for example, when the thread finishes execution, is terminated, or returns to the thread pool), the context information associated with that task and bound to the execution thread will be automatically released or destroyed by the system. This automatic destruction mechanism ensures that resources can be reclaimed in a timely manner without the need for additional manual intervention. This can be achieved by, but is not limited to, leveraging the automatic garbage collection mechanism provided by the programming language or runtime environment; storing context information in thread-local storage (TLS), which is automatically cleaned up when the thread terminates; or using memory management techniques such as smart pointers and reference counting to ensure that the memory occupied by the context information is automatically released when it is no longer referenced.

[0052] The solution of the present application effectively solves the problem of resource accumulation caused by the failure to release context information in a timely manner by automatically destroying the context information of the corresponding task after the life cycle of the execution thread ends. When a task is completed and its execution thread no longer needs the context information, the memory resources occupied by the information will be immediately reclaimed. This mechanism avoids the continuous growth of system memory usage as the number of tasks increases, thereby effectively preventing potential memory leaks and resource exhaustion problems. It is precisely because of this automated resource cleanup that the system can run stably for a long time, especially in scenarios where a large number of concurrent tasks or short-lifecycle tasks are processed, its advantages are more significant.

[0053] Reference Attachment Figure 2 , the present invention provides a multi-language hybrid system, comprising a plurality of heterogeneous language modules 100 and a central scheduling unit 200, each of which is deployed with a corresponding language adaptation unit; The heterogeneous language module 100 is used to perform the following steps: After a task is created locally, the corresponding language adaptation unit is controlled according to the initiating language used by the task, a task request data structure for the task is constructed, and the task request data structure is submitted to the central scheduling unit; the task request data structure includes the context information of the corresponding task; The central scheduling unit 200 is configured to perform the following steps: Periodically receive and maintain thread resource status information from various heterogeneous language modules; After receiving the task, a scheduling decision is made for the task based on the task request data structure and thread resource status information of the task, and a target heterogeneous language module is determined; Distributing the task to the language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined after the task scheduling decision; The heterogeneous language module 100 is further configured to perform the following steps: After receiving the task, an execution thread is created, and the context information of the task is bound to the life cycle of the execution thread, and the task is executed through the execution thread; After the task is completed, the corresponding language adaptation unit is controlled to report the execution result of the task to the central scheduling unit.

[0054] In some embodiments, after receiving the task, the central scheduling unit 200 is configured to make a scheduling decision for the task based on the task request data structure and thread resource status information of the task, and determine the target heterogeneous language module when performing the following: After receiving the task, a scheduling decision is made for the task based on the task's function identifier, initiating language, priority, estimated resource usage, and thread resource status information, and the target heterogeneous language module is determined.

[0055] In some embodiments, after receiving the task, the central scheduling unit 200 is configured to make a scheduling decision for the task based on the function identifier, initiating language, priority, estimated resource usage, and thread resource status information of the task, and to determine the target heterogeneous language module when performing the following: A1. If the thread resources of the heterogeneous language module corresponding to the initiating language are greater than or equal to the estimated resource usage of the task, the heterogeneous language module corresponding to the initiating language is deemed to have sufficient resources and is determined as the target heterogeneous language module. A2. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task does not indicate that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is deemed to be resource-constrained. Based on the thread resource status information, another heterogeneous language module with thread resources greater than or equal to the estimated resource usage of the task is selected and determined as the target heterogeneous language module. A3. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task indicates that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module. In a subsequent dispatch step, the task is added to the waiting queue of the target heterogeneous language module according to its priority, and is thereby executed sequentially according to the waiting queue.

[0056] Please refer to Figure 3 , Figure 3A thread-compatible scheduling device in some embodiments of the present invention is applied to a multi-language hybrid system. The multi-language hybrid system includes multiple heterogeneous language modules 100 and a central scheduling unit 200. Each heterogeneous language module 100 is deployed with a corresponding language adaptation unit. The thread-compatible scheduling device is integrated into a back-end control device in the form of a computer program and includes: Construction module 300 is used to, after a task is created locally, control the language adaptation unit in the heterogeneous language module corresponding to the initiating language used by the task, construct a task request data structure for the task, and submit the task request data structure to the central scheduling unit; the task request data structure includes context information of the corresponding task; The receiving and maintaining module 400 is used to control the central scheduling unit to periodically receive and maintain thread resource status information from each heterogeneous language module; The decision module 500 is used to control the central scheduling unit to make a scheduling decision for the task and determine the target heterogeneous language module according to the task request data structure and thread resource status information of the task after the central scheduling unit receives the task; A distribution module 600 is configured to distribute the task to the language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined after the task scheduling decision; The control execution module 700 is used to control the target heterogeneous language module to create an execution thread after receiving the task, bind the context information of the task to the life cycle of the execution thread, and execute the task through the execution thread; The reporting module 800 is used to control the language adaptation unit in the target heterogeneous language module to report the execution result of the task to the central scheduling unit after the task is completed.

[0057] In some embodiments, after the central scheduling unit receives the task, the decision module 500 controls the central scheduling unit to make a scheduling decision for the task based on the task request data structure and thread resource status information of the task, and determines the target heterogeneous language module to execute the following: After receiving the task, the central scheduling unit is controlled to make a scheduling decision for the task based on the function identifier, initiating language, priority, estimated resource usage, and thread resource status information of the task, and determine the target heterogeneous language module.

[0058] In some embodiments, after the central scheduling unit receives the task, the decision module 500 controls the central scheduling unit to make a scheduling decision for the task based on the function identifier, initiating language, priority, estimated resource usage, and thread resource status information of the task, and performs the following when determining the target heterogeneous language module: A1. If the thread resources of the heterogeneous language module corresponding to the initiating language are greater than or equal to the estimated resource usage of the task, the heterogeneous language module corresponding to the initiating language is deemed to have sufficient resources and is determined as the target heterogeneous language module. A2. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task does not indicate that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is deemed to be resource-constrained. Based on the thread resource status information, another heterogeneous language module with thread resources greater than or equal to the estimated resource usage of the task is selected and determined as the target heterogeneous language module. A3. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task indicates that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module. In a subsequent dispatch step, the task is added to the waiting queue of the target heterogeneous language module according to its priority, and is thereby executed sequentially according to the waiting queue.

[0059] Please refer to Figure 4 , Figure 4This is a structural diagram of an electronic device provided by an embodiment of the present invention. The present invention provides an electronic device 13, including: a processor 1301 and a memory 1302. The processor 1301 and the memory 1302 are interconnected and communicate with each other via a communication bus 1303 and / or other forms of connection mechanisms (not shown). The memory 1302 stores computer-readable instructions executable by the processor 1301. When the electronic device is running, the processor 1301 executes the computer-readable instructions to execute the thread-compatible scheduling method in any optional implementation of the above embodiment to achieve the following functions: after a task is created locally, according to the initiating language used by the task, the language adaptation unit in the heterogeneous language module corresponding to the initiating language is controlled to construct a task request data structure for the task, and the task request data structure is submitted to the central scheduling unit; any The task request data structure includes context information of the corresponding task; the central scheduling unit is controlled to periodically receive and maintain thread resource status information from each heterogeneous language module; after the central scheduling unit receives the task, the central scheduling unit is controlled to make a scheduling decision for the task based on the task request data structure and thread resource status information of the task, and determine the target heterogeneous language module; according to the target heterogeneous language module determined after the task scheduling decision, the task is distributed to the language adaptation unit of the target heterogeneous language module; after the target heterogeneous language module receives the task, the target heterogeneous language module is controlled to create an execution thread, and the context information of the task is bound to the life cycle of the execution thread, and the task is executed through the execution thread; after the task is executed, the language adaptation unit in the target heterogeneous language module is controlled to report the execution result of the task to the central scheduling unit.

[0060] An embodiment of the present invention provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the thread-compatible scheduling method in any optional implementation of the above embodiment is executed to achieve the following functions: after a task is created locally, according to the initiating language used by the task, the language adaptation unit in the heterogeneous language module corresponding to the initiating language is controlled to construct a task request data structure for the task, and the task request data structure is submitted to the central scheduling unit; the task request data structure includes context information of the corresponding task; the central scheduling unit is controlled to periodically receive and maintain thread resource status information from each heterogeneous language module; in the central scheduling unit After receiving the task, the central scheduling unit is controlled to make a scheduling decision for the task based on the task request data structure and thread resource status information of the task, and determine the target heterogeneous language module; according to the target heterogeneous language module determined after the task scheduling decision, the task is distributed to the language adaptation unit of the target heterogeneous language module; after the target heterogeneous language module receives the task, the target heterogeneous language module is controlled to create an execution thread, and the context information of the task is bound to the life cycle of the execution thread, and the task is executed through the execution thread; after the task is completed, the language adaptation unit in the target heterogeneous language module is controlled to report the execution result of the task to the central scheduling unit.

[0061] Among them, the computer-readable storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk or optical disk.

[0062] In the embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed may be through some communication interface, the indirect coupling or communication connection of the device or unit may be electrical, mechanical or other forms.

[0063] In addition, the units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0064] Furthermore, the functional modules in the various embodiments of the present invention may be integrated together to form an independent part, or each module may exist independently, or two or more modules may be integrated to form an independent part.

[0065] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any actual relationship or order between these entities or operations.

[0066] The foregoing description is merely an embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Those skilled in the art will readily appreciate that the present invention is susceptible to various modifications and variations. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of the present invention shall be included within the scope of protection of the present invention.

Claims

1. A thread-compatible scheduling method, applied to a multi-language hybrid system, characterized in that: The multi-language hybrid system includes a plurality of heterogeneous language modules and a central scheduling unit, and each of the heterogeneous language modules is deployed with a corresponding language adaptation unit; The thread compatible scheduling method comprises the following steps: After a task is created locally, the language adaptation unit in the heterogeneous language module corresponding to the initiating language used by the task is controlled to construct a task request data structure for the task, and submit the task request data structure to the central scheduling unit; the task request data structure includes context information of the corresponding task; Controlling the central scheduling unit to periodically receive and maintain thread resource status information from each of the heterogeneous language modules; After the central scheduling unit receives the task, controlling the central scheduling unit to make a scheduling decision for the task and determine a target heterogeneous language module according to the task request data structure and the thread resource status information of the task; Distributing the task to a language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined after the task scheduling decision; After the target heterogeneous language module receives the task, the target heterogeneous language module is controlled to create an execution thread, and the context information of the task is bound to the life cycle of the execution thread, and the task is executed through the execution thread; After the task is completed, the language adaptation unit in the target heterogeneous language module is controlled to report the execution result of the task to the central scheduling unit.

2. The thread-compatible scheduling method according to claim 1, characterized in that: The task request data structure also includes a function identifier, an initiating language, a priority, and an estimated resource occupancy of the corresponding task.

3. The thread-compatible scheduling method according to claim 1, wherein: The thread resource status information includes the number of active threads, the maximum capacity of the thread pool, and the current resource usage.

4. The thread-compatible scheduling method according to claim 2, wherein: After the central scheduling unit receives the task, the steps of controlling the central scheduling unit to make a scheduling decision for the task based on the task request data structure and the thread resource status information, and determining the target heterogeneous language module include: After the central scheduling unit receives the task, it controls the central scheduling unit to make a scheduling decision for the task and determine a target heterogeneous language module according to the function identifier, initiating language, priority, estimated resource occupancy and thread resource status information of the task.

5. The thread-compatible scheduling method according to claim 4, characterized in that: After the central scheduling unit receives the task, the step of controlling the central scheduling unit to make a scheduling decision for the task based on the function identifier, initiating language, priority, estimated resource usage, and thread resource status information of the task, and determining the target heterogeneous language module includes: A1. If the thread resources of the heterogeneous language module corresponding to the initiating language are greater than or equal to the estimated resource usage of the task, the heterogeneous language module corresponding to the initiating language is deemed to have sufficient resources and is determined as the target heterogeneous language module. A2. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task does not indicate that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is deemed to be resource-constrained. Based on the thread resource status information, another heterogeneous language module whose thread resources are greater than or equal to the estimated resource usage of the task is selected and determined as the target heterogeneous language module. A3. If the thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource usage of the task, and the function identifier of the task indicates that the task can only be executed by the heterogeneous language module corresponding to the initiating language, the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module, so that in a subsequent distribution step, the task is added to the waiting queue of the target heterogeneous language module according to the priority of the task, and is thereby executed sequentially according to the waiting queue.

6. The thread-compatible scheduling method according to claim 1, characterized in that: After the life cycle of the execution thread ends, the context information of the corresponding task bound to the execution thread is automatically destroyed.

7. A multi-language hybrid system, characterized in that: It includes multiple heterogeneous language modules and a central scheduling unit, and each of the heterogeneous language modules is deployed with a corresponding language adaptation unit; The heterogeneous language module is used to perform the following steps: After a task is created locally, the corresponding language adaptation unit is controlled according to the initiating language used by the task to construct a task request data structure for the task and submit the task request data structure to the central scheduling unit; the task request data structure includes context information of the corresponding task; The central dispatching unit is configured to perform the following steps: Periodically receiving and maintaining thread resource status information from each of the heterogeneous language modules; After receiving the task, a scheduling decision is made for the task based on the task request data structure and the thread resource status information of the task, and a target heterogeneous language module is determined; Distributing the task to a language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined after the task scheduling decision; The heterogeneous language module is further configured to perform the following steps: After receiving the task, an execution thread is created, and the context information of the task is bound to the life cycle of the execution thread, and the task is executed through the execution thread; After the task is completed, the corresponding language adaptation unit is controlled to report the execution result of the task to the central scheduling unit.

8. A thread-compatible scheduling device, applied to a multi-language hybrid system, characterized in that: The multi-language hybrid system includes a plurality of heterogeneous language modules and a central scheduling unit, and each of the heterogeneous language modules is deployed with a corresponding language adaptation unit; The thread-compatible scheduling device includes: a construction module configured to, after a task is created locally, control the language adaptation unit in the heterogeneous language module corresponding to the initiating language used by the task, construct a task request data structure for the task, and submit the task request data structure to the central scheduling unit; the task request data structure includes context information of the corresponding task; a receiving and maintaining module, configured to control the central scheduling unit to periodically receive and maintain thread resource status information from each of the heterogeneous language modules; a decision module, configured to control the central scheduling unit to make a scheduling decision for the task and determine a target heterogeneous language module based on the task request data structure and the thread resource status information of the task after the central scheduling unit receives the task; a distribution module, configured to distribute the task to a language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined after the task scheduling decision; a control execution module, configured to control the target heterogeneous language module to create an execution thread after the target heterogeneous language module receives the task, bind the context information of the task to the life cycle of the execution thread, and execute the task through the execution thread; The reporting module is used to control the language adaptation unit in the target heterogeneous language module to report the execution result of the task to the central scheduling unit after the task is completed.

9. An electronic device, characterized in that: The system comprises a processor and a memory, wherein the memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the steps of the thread-compatible scheduling method according to any one of claims 1 to 6 are executed.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the thread-compatible scheduling method according to any one of claims 1 to 6 are executed.

Images