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

Abstract

The application provides a thread compatible scheduling method, a multi-language mixed system, a device and related equipment thereof, and relates to the technical field of computer control. The method submits tasks 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 makes scheduling decisions according to the thread resource state, including preferentially scheduling to the initiating language module, or scheduling to other abundant modules supporting the function when resources are tight, or adding the task to a waiting queue; after the task is distributed to the target module, the language adaptation unit creates a thread and binds the task context to execute the task; after the task is completed, the execution result is reported to the central scheduling unit. The method aims to solve the problems of thread scheduling splitting, resource conflict, context rupture and the like in a multi-language environment that cannot be solved by the prior art, and is beneficial to improving the performance, stability and maintainability of a high-concurrency system.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer control, in particular to a thread compatible scheduling method, a multi-language mixed system, a device and related equipment thereof. BACKGROUND

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

[0003] Each language usually runs in its own independent runtime environment (such as java, python, C / C++ in JVM, CPython, and Native Thread respectively), and is equipped with its own thread pool or task execution model. For example:

[0004] Java runs on JVM (Java Virtual Machine), and common concurrency models include ThreadPoolExecutor and ForkJoinPool, which are widely used in multi-threaded task scheduling and parallel computing;

[0005] Python usually runs in the CPython interpreter and supports multiple concurrency mechanisms: ThreadPoolExecutor based on threads is suitable for I / O-intensive tasks, ProcessPoolExecutor based on processes can bypass the Global Interpreter Lock (GIL) to handle CPU-intensive tasks, and the asyncio coroutine model based on event loops is provided for high-concurrency asynchronous I / O scenarios;

[0006] C++ is compiled into native machine code and runs in the native thread environment provided by the operating system, and common concurrency models include std::thread in the standard library, thread pool implementation, and third-party libraries such as Boost.Thread, which can achieve high-performance multi-threaded concurrency control.

[0007] In this multi-language mixed architecture, existing systems have the following problems in concurrent task scheduling and thread resource usage:

[0008] 1. Independent scheduling of each language thread pool, lack of coordination:

[0009] Each language module is unaware of the use of thread pool resources, and multiple large thread pools can be started on the same operating system, causing excessive resource consumption and frequent thread context switching, resulting in sustained high CPU load, system lag or thread starvation, lack of global thread scheduling strategy, and thread priority management chaos.

[0010] 2. Task scheduling is not unified:

[0011] Current thread scheduling decisions are limited to individual language modules, making it difficult to coordinate across languages. For example, while a Java module is executing a high-priority task, a Python module may simultaneously initiate a low-priority request, causing important tasks to be preempted for resources and making task response time uncontrollable.

[0012] 3. Context loss, thread ownership difficult to maintain:

[0013] In cross-language call chains (such as Java calling Python, and Python calling C++), due to the lack of shared runtime context between languages, there are often problems such as broken log links, failed request tracking, and loss of user identity information and call parameters in the middle, and there is a lack of unified context transfer mechanism, making it difficult to meet audit and security requirements.

[0014] 4. Unable to collect task status and thread health indicators uniformly:

[0015] Multiple language thread pools run independently, making debugging and monitoring difficult, especially in large-scale deployment scenarios, and there is a lack of unified task status query and thread health monitoring means, increasing system maintenance complexity.

[0016] In summary, existing technologies cannot solve the problems of thread scheduling fragmentation, resource conflict, and context breakage in a multi-language environment, which restricts the performance, stability, and maintainability of high-concurrency systems.

[0017] Currently, there is no effective technical solution to the above problems. SUMMARY

[0018] The purpose of the present application is to provide a thread-compatible scheduling method, a multi-language hybrid system, a device and related equipment, aiming to solve the problems of thread scheduling fragmentation, resource conflict, and context breakage in a multi-language environment that existing technologies cannot solve, and to improve the performance, stability, and maintainability of high-concurrency systems.

[0019] In a first aspect, the present application provides a thread-compatible scheduling method applied to a multi-language hybrid system, the multi-language hybrid system comprising a plurality of heterogeneous language modules and a central scheduling unit, each of the heterogeneous language modules being deployed with a corresponding language adaptation unit.

[0020] The thread-compatible scheduling method comprises the following steps:

[0021] After the task is created locally, according to the starting language adopted by the task, a language adaptation unit in a heterogeneous language module corresponding to the starting 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 comprises context information of the corresponding task;

[0022] The central scheduling unit is controlled to periodically receive and maintain thread resource state information from each of the heterogeneous language modules;

[0023] After the central scheduling unit receives the task, the central scheduling unit is controlled to make a scheduling decision for the task according to the task request data structure of the task and the thread resource state information, and determine a target heterogeneous language module;

[0024] According to the target heterogeneous language module determined by the scheduling decision of the task, the task is distributed to a language adaptation unit of the target heterogeneous language module;

[0025] After the target heterogeneous language module receives the task, the target heterogeneous language module is controlled to create an execution thread, bind the context information of the task to the life cycle of the execution thread, and execute the task through the execution thread;

[0026] After the task is executed and 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.

[0027] The thread-compatible scheduling method of the application, by introducing the architecture of “central scheduling unit + language adaptation unit”, realizes unified registration, scheduling decision, thread allocation and context maintenance of heterogeneous language tasks, and is beneficial to improving the performance, stability and maintainability of a high-concurrency system.

[0028] Further, the task request data structure further comprises a function identifier, a starting language, a priority and an estimated resource occupation amount of the corresponding task.

[0029] Further, the thread resource state information comprises the number of active threads, the maximum capacity of a thread pool and the current resource occupation situation.

[0030] Further, after the central scheduling unit receives the task, the central scheduling unit is controlled to make a scheduling decision for the task according to the task request data structure of the task and the thread resource state information, and determine a target heterogeneous language module, which comprises the following steps:

[0031] After the central scheduling unit receives the task, the central scheduling unit is controlled to make a scheduling decision for the task according to the function identifier, the initiating language, the priority, the estimated resource occupation amount of the task, and the thread resource state information, and determine a target heterogeneous language module.

[0032] Further, after the central scheduling unit receives the task, the step of controlling the central scheduling unit to make a scheduling decision for the task according to the function identifier, the initiating language, the priority, the estimated resource occupation amount of the task, and the thread resource state information, and determine a target heterogeneous language module includes:

[0033] A1. If the thread resource of the heterogeneous language module corresponding to the initiating language is greater than or equal to the estimated resource occupation amount of the task, the heterogeneous language module corresponding to the initiating language is considered to be resource sufficient, and the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module;

[0034] A2. If the thread resource of the heterogeneous language module corresponding to the initiating language is less than the estimated resource occupation amount 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 considered to be resource nervous, and according to the thread resource state information, other heterogeneous language modules with thread resources greater than or equal to the estimated resource occupation amount of the task are selected and determined as the target heterogeneous language module;

[0035] A3. If the thread resource of the heterogeneous language module corresponding to the initiating language is less than the estimated resource occupation amount 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 the task is added to the waiting queue of the target heterogeneous language module according to the priority of the task in the subsequent distribution step, and is executed in turn according to the waiting queue.

[0036] The problem of excessive load of a single heterogeneous language module caused by task concentration or resource shortage is effectively avoided, and the stability and reliability of the multi-language hybrid system are significantly enhanced. At the same time, the ordered execution of the system in a resource nervous situation is ensured, and the fault tolerance and business continuity of the system are further improved.

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

[0038] In a second aspect, the present application provides a multi-language hybrid system, comprising a plurality of heterogeneous language modules and a central scheduling unit, each of the heterogeneous language modules being deployed with a corresponding language adaptation unit;

[0039] The heterogeneous language modules are configured to perform the following steps:

[0040] After a task is created locally, a corresponding language adaptation unit is controlled according to an initiating language adopted 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 comprises context information of the corresponding task;

[0041] The central scheduling unit is configured to perform the following steps:

[0042] Periodically receiving and maintaining thread resource state information from each of the heterogeneous language modules;

[0043] After receiving the task, a scheduling decision for the task is made according to the task request data structure of the task and the thread resource state information, and a target heterogeneous language module is determined;

[0044] According to the target heterogeneous language module determined by the task scheduling decision, the task is distributed to the language adaptation unit of the target heterogeneous language module;

[0045] The heterogeneous language modules are further configured to perform the following steps:

[0046] 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;

[0047] After the task is executed, the corresponding language adaptation unit is controlled to report the execution result of the task to the central scheduling unit.

[0048] The multi-language hybrid system of the present application can effectively avoid resource overconsumption and thread starvation, optimize the efficiency of thread context switching, and ensure timely response of high-priority tasks. In addition, it also ensures data consistency and traceability, significantly improving the stability, maintainability and overall performance of the system.

[0049] In a third aspect, the present application provides a thread compatible scheduling device, applied to a multi-language hybrid system, the multi-language hybrid system comprising a plurality of heterogeneous language modules and a central scheduling unit, each of the heterogeneous language modules being deployed with a corresponding language adaptation unit;

[0050] The thread compatible scheduling device comprises:

[0051] The construction module is configured to, after a task is created locally, control a language adaptation unit in a heterogeneous language module corresponding to an initiation language adopted by the task according to the initiation language, 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 comprises context information of the corresponding task;

[0052] The receiving and maintaining module is configured to control the central scheduling unit to periodically receive and maintain thread resource state information from each of the heterogeneous language modules;

[0053] The decision module is configured to, after the central scheduling unit receives the task, control the central scheduling unit to make a scheduling decision for the task according to the task request data structure of the task and the thread resource state information, and determine a target heterogeneous language module;

[0054] The distribution module is configured to, according to the target heterogeneous language module determined after the scheduling decision for the task, distribute the task to the language adaptation unit of the target heterogeneous language module;

[0055] The control execution module is configured to, after the target heterogeneous language module receives the task, control the target heterogeneous language module to create an execution thread, bind the context information of the task to a life cycle of the execution thread, and execute the task through the execution thread;

[0056] The reporting module is configured to, after the task is executed and completed, control the language adaptation unit in the target heterogeneous language module to report an execution result of the task to the central scheduling unit.

[0057] Compared with the independent scheduling of each language module, the mutual unawareness of resources and the loss of context in the prior art, the thread compatible scheduling device provided by the application realizes the global view and unified scheduling of thread resources in a multi-language mixed system by introducing a central scheduling unit.

[0058] In a fourth aspect, the application provides an electronic device including a processor and a memory, and 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.

[0059] In a fifth aspect, the application provides a computer readable storage medium, and the computer readable storage medium stores a computer program, when the computer program is executed by a processor, the steps of the thread compatible scheduling method provided in the first aspect are executed.

[0060] As can be seen from the above, the thread compatible scheduling method provided by the application has the following advantages:

[0061] 1. Unified scheduling strategy: centralized scheduling of multi-language module tasks, solving the thread explosion problem, improving resource utilization;

[0062] 2. Complete context transfer: maintain complete task call chain, support log audit, link tracking, security control, etc.;

[0063] 3. Task priority consistency: high priority tasks will not be preempted by language boundaries, ensuring the stability of critical processes;

[0064] 4. Cross-language thread ownership awareness: thread management is no longer limited to language, which is beneficial to thread isolation, fusing and flow limiting;

[0065] 5. Universality and scalability: can access any language module, only need to implement language adaptation.

[0066] Other features and advantages of the present application will be set forth in the following description, and in part will become apparent from the description, or can be learned by practice of the application. The objects and other advantages of the present application can be achieved and obtained by the structure particularly pointed out in the written description and drawings. BRIEF DESCRIPTION OF DRAWINGS

[0067] Figure 1 A flow chart of the thread compatible scheduling method provided by the embodiment of the present application.

[0068] Figure 2 A structural schematic diagram of the multi-language hybrid system provided by the embodiment of the present application.

[0069] Figure 3 A structural schematic diagram of the thread compatible scheduling device provided by the embodiment of the present application.

[0070] Figure 4 A structural schematic diagram of the electronic device provided by the embodiment of the present application.

[0071] Label explanation:

[0072] 100, heterogeneous language module; 200, central scheduling unit; 300, construction module; 400, receiving and maintaining 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

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

[0074] It should be noted that similar reference numerals and letters refer to like items in the accompanying drawings, and therefore, once an item is defined in one drawing, it need not be further defined and explained in subsequent drawings. Meanwhile, in the description of the present application, the terms "first", "second", and the like are only used to distinguish description, and cannot be understood as indicating or implying relative importance.

[0075] With reference to the accompanying drawings, Figure 1 The present application provides a thread-compatible scheduling method, which is applied to a multi-language hybrid system, the multi-language hybrid system comprising a plurality of heterogeneous language modules (for example, Java heterogeneous language modules, Python heterogeneous language modules, C++ heterogeneous language modules) and a central scheduling unit, each of the heterogeneous language modules being deployed with a corresponding language adaptation unit (the language adaptation unit can communicate with the central scheduling unit in the manner of HTTP or gRPC, etc.);

[0076] The thread-compatible scheduling method comprises the following steps:

[0077] After the task is created locally, the language adaptation unit in the heterogeneous language module corresponding to the initiating language of the task is controlled according to the initiating language of 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 comprises context information of the corresponding task;

[0078] The central scheduling unit is controlled to periodically receive and maintain thread resource state information from each of the heterogeneous language modules;

[0079] After the central scheduling unit receives the task, the central scheduling unit is controlled to make a scheduling decision for the task according to the task request data structure of the task and the thread resource state information, and determine a target heterogeneous language module;

[0080] According to the target heterogeneous language module determined by the scheduling decision of the task, the task is distributed to the language adaptation unit of the target heterogeneous language module;

[0081] After the target heterogeneous language module receives the task, it controls the target heterogeneous language module to create an execution thread and binds the context information of the task 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, realizes the consistency of cross-language data transmission, and executes the task through the execution thread;

[0082] After the task is executed, the language adaptation unit in the target heterogeneous language module reports the execution result of the task to the central scheduling unit.

[0083] Specifically, after the task is created, it is first encapsulated into a task request data structure by the language adaptation unit in the local heterogeneous language module. The data structure carries the basic information and important context information of the task, such as the unique identifier of the task, the initiator information, and any data that needs to be consistent during task execution. The task request data structure is then submitted to the central scheduling unit as the basis for subsequent scheduling decisions.

[0084] At the same time, the central scheduling unit continuously collects and updates the current thread resource state information of each heterogeneous language module. These information can include but not limited to the thread pool usage, the number of idle threads, and potential resource bottlenecks of each module. These real-time state information is crucial for the central scheduling unit to make efficient and reasonable scheduling decisions.

[0085] When the central scheduling unit receives the task request, it analyzes the task characteristics (such as the initiating language) contained in the task request data structure and the thread resource state information of each heterogeneous language module. Based on these information, the central scheduling unit makes scheduling decisions to determine the target heterogeneous language module that is most suitable for executing the task. For example, the corresponding module can be selected according to the initiating language of the task, or other compatible modules can be considered when resources are scarce.

[0086] 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, it creates a new execution thread. A key step is to bind the context information of the task (such as user ID, task request ID, transaction information, etc.) to the life cycle of the execution thread (such as using Java's ThreadLocal, Python's ContextVar, etc. to save the incoming information). This means that during the entire execution of the task, it can access its original context information at any time, regardless of the language environment it runs in, thereby ensuring the consistency of cross-language data transmission. Subsequently, the task is actually executed through the created execution thread.

[0087] After the task is completed, the language adaptation unit in the target heterogeneous language module is responsible for collecting the execution results of the task and reporting them to the central scheduling unit. The central scheduling unit can update the task status and record it into the system log or database, thereby forming a complete task life cycle management closed loop and realizing cross-language link tracking.

[0088] Compared with the disadvantages of independent scheduling of each language module, mutual unawareness of resources, and easy loss of context in the prior art, the scheme of the present application realizes a global view and unified scheduling of thread resources in a multi-language mixed system by introducing a central scheduling unit. This centralized scheduling strategy can effectively avoid excessive consumption of resources and thread starvation, optimize the efficiency of thread context switching, and ensure timely response of high-priority tasks. In addition, by binding the task context information to the life cycle of the execution thread, the problem of context loss in the cross-language call chain is solved, ensuring data consistency and traceability, and significantly improving the stability, maintainability, and overall performance of the system.

[0089] 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 occupancy (such as CPU or memory occupancy), and a callback address of the corresponding task.

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

[0091] In some embodiments, after the central scheduling unit receives the task, the step of controlling the central scheduling unit to determine the target heterogeneous language module based on the task request data structure and the thread resource state information of the task includes:

[0092] After the central scheduling unit receives the task, the step of controlling the central scheduling unit to determine the target heterogeneous language module based on the function identifier, the initiating language, the priority, the estimated resource occupancy, and the thread resource state information of the task includes:

[0093] Further, after the central scheduling unit receives the task, the step of controlling the central scheduling unit to determine the target heterogeneous language module based on the function identifier, the initiating language, the priority, the estimated resource occupancy, and the thread resource state information of the task includes:

[0094] A1. If the thread resource of the heterogeneous language module corresponding to the initiating language is greater than or equal to the estimated resource occupancy of the task, the heterogeneous language module corresponding to the initiating language is considered to be resource sufficient, and the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module;

[0095] A2. If the thread resource of the heterogeneous language module corresponding to the initiating language is less than the estimated resource occupancy 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 considered to be resource insufficient, and according to the thread resource state information, other heterogeneous language modules with thread resources greater than or equal to the estimated resource occupancy of the task are selected and determined as the target heterogeneous language module, so as to realize equivalent function replacement scheduling, reduce the task dispatching frequency of a single heterogeneous language module, avoid high-overhead tasks from being concentrated on a single heterogeneous language module for execution, thereby avoiding the load of a single heterogeneous language module from being too high, and further ensuring the stability of the system as a whole.

[0096] A3. If the thread resource of the heterogeneous language module corresponding to the initiating language is less than the estimated resource occupancy 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 the task is added to the waiting queue of the target heterogeneous language module according to the priority of the task in the subsequent dispatching step, and is executed in turn according to the waiting queue.

[0097] Specifically, in step A1, when the current thread resource (for example, the comprehensive evaluation of the number of active threads, the maximum capacity of the thread pool and the current resource occupancy) of the heterogeneous language module corresponding to the initiating language of the task can meet the estimated resource occupancy of the task, it indicates that the module has the ability to immediately process the task. Therefore, the task is directly scheduled to the heterogeneous language module corresponding to the initiating language for execution, so as to maintain the locality and efficiency of task processing.

[0098] In step A2, when the thread resources of the heterogeneous language module corresponding to the initiation language of the task are insufficient to meet the estimated resource occupation of the task, in order to avoid overloading of the module, the central scheduling unit will find other heterogeneous language modules with sufficient thread resources and capable of executing the task according to the collected thread resource state information of each heterogeneous language module. Among them, "equivalent function replacement scheduling" refers to if the function of a task can be implemented by multiple languages or modules, when the resource of the heterogeneous language module of the original initiation language is tight, it can be scheduled to other heterogeneous language modules with equivalent function to execute, so as to realize load balancing. For example, image recognition, data cleaning and other modules have implementations in Java and Python, so these tasks can be dispatched to Java heterogeneous language modules for execution, or to Python heterogeneous language modules for execution, at this time, Java heterogeneous language modules and Python heterogeneous language modules have equivalent functions for the task, so according to the resource state of the two, replacement scheduling can be carried out to realize efficient completion of the task.

[0099] In step A3, there is a special case, that is, although the resource of the heterogeneous language module corresponding to the initiation language is tight, the function identifier of the task clearly indicates that it can only be executed by the specific heterogeneous language module (for example, functionType only supports execution in Java heterogeneous language module, and the current thread pool of Java heterogeneous language module is busy, then the task enters the waiting queue of 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 the initiation 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 turn after the resource is released.

[0100] The scheme of the present application effectively solves the problems of resource imbalance and overload that may occur in heterogeneous language modules in a multi-language mixed system by introducing fine scheduling decision logic. Specifically, after a task is created and submitted to the central scheduling unit, the central scheduling unit will comprehensively consider the characteristics of the task (such as function identification, estimated resource occupancy) and the real-time thread resource state information of each heterogeneous language module. First, through step A1, for the heterogeneous language module with sufficient resources, the task can be quickly and directly scheduled, ensuring efficient local processing. Second, through step A2, when the heterogeneous language module corresponding to the launch language is in a state of resource shortage, the system can intelligently perform equivalent function substitution scheduling. This means that if other heterogeneous language modules have the ability to perform the same or equivalent function and have sufficient resources, the task will be distributed to these substitute modules. This mechanism effectively reduces the task distribution frequency of a single heterogeneous language module, avoids high-overhead tasks from being executed on a single module, thereby significantly reducing the load pressure on a specific module, preventing system performance degradation or collapse due to local overload, and thus ensuring the stability and flexibility of the system as a whole. Finally, through step A3, for tasks with strong module dependency that cannot be substituted, even if the heterogeneous language module corresponding to the launch language is in a state of resource shortage, the system can ensure that these tasks are eventually processed. By adding them to the waiting queue of the target heterogeneous language module and executing them in order according to priority, the reliability of critical tasks is ensured, avoiding task loss or long blocking due to temporary resource shortage, thereby maintaining the integrity of system functions.

[0101] Through the above technical solution, the present application can achieve more intelligent and robust thread compatibility scheduling. Specifically, this scheme not only optimizes the scheduling path of the task and improves resource utilization, but more importantly, it introduces an equivalent function substitution scheduling mechanism to effectively avoid the problem of excessive load on a single heterogeneous language module due to task concentration or resource shortage, significantly enhancing the stability and reliability of the multi-language mixed system. At the same time, for tasks with specific module dependencies, through priority queue management, the ordered execution of these tasks in a resource shortage situation is ensured, further improving the fault tolerance and business continuity of the system.

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

[0103] This means that once an execution thread finishes its task and ends its life cycle (e.g., the thread is executed, terminated, or returned to the thread pool), the context information associated with the 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 recycled in a timely manner without additional manual intervention. Its implementation can include but is not limited to: using the automatic garbage collection mechanism provided by the programming language or runtime environment; storing context information in thread-local storage (TLS), and when the thread terminates, the data in TLS is automatically cleaned up; or using smart pointers, reference counting, and other memory management techniques to ensure that when the context information is no longer referenced, the memory it occupies is automatically released.

[0104] The scheme 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 are immediately recycled. 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 involving a large number of concurrent tasks or short-life cycle tasks, where the advantages are more pronounced.

[0105] Reference is made to the accompanying drawings Figure 2 The present application 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;

[0106] The heterogeneous language module 100 is used to perform the following steps:

[0107] After the task is created locally, the corresponding language adaptation unit is controlled according to the initiation 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;

[0108] The central scheduling unit 200 is used to perform the following steps:

[0109] Periodically receive and maintain thread resource state information from each heterogeneous language module;

[0110] After receiving the task, the task is scheduled according to the task request data structure of the task and the thread resource state information, and the target heterogeneous language module is determined;

[0111] According to the target heterogeneous language module determined after the task scheduling decision, the task is distributed to a language adaptation unit of the target heterogeneous language module;

[0112] The heterogeneous language module 100 is further configured to perform the following steps:

[0113] After receiving the task, an execution thread is created, and context information of the task is bound to a life cycle of the execution thread, and the task is executed through the execution thread;

[0114] After the task is executed, the corresponding language adaptation unit is controlled to report the execution result of the task to the central scheduling unit.

[0115] In some embodiments, the central scheduling unit 200 is configured to, when receiving the task, perform the following steps to determine the target heterogeneous language module according to the task request data structure of the task and the thread resource state information:

[0116] After receiving the task, the target heterogeneous language module is determined according to the function identifier, the initiating language, the priority, the estimated resource occupancy, and the thread resource state information of the task.

[0117] In some embodiments, the central scheduling unit 200 is configured to, when receiving the task, perform the following steps to determine the target heterogeneous language module according to the function identifier, the initiating language, the priority, the estimated resource occupancy, and the thread resource state information of the task:

[0118] A1. If the thread resource of the heterogeneous language module corresponding to the initiating language is greater than or equal to the estimated resource occupancy of the task, the heterogeneous language module corresponding to the initiating language is considered to be resource sufficient, and the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module;

[0119] A2. If the thread resource of the heterogeneous language module corresponding to the initiating language is less than the estimated resource occupancy 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 considered to be resource stressed, and according to the thread resource state information, other heterogeneous language modules whose thread resources are greater than or equal to the estimated resource occupancy of the task are selected and determined as the target heterogeneous language module;

[0120] A3. If the thread resource of the heterogeneous language module corresponding to the initiating language is less than the estimated resource occupancy 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 the task is added to the waiting queue of the target heterogeneous language module in the subsequent distribution step according to the priority of the task, and is executed in turn according to the waiting queue.

[0121] Please refer to Figure 3 , Figure 3 is a thread compatible scheduling device in some embodiments of the application, applied to a multi-language mixed system, the multi-language mixed system comprising a plurality of heterogeneous language modules 100 and a central scheduling unit 200, and each of the heterogeneous language modules 100 is provided with a corresponding language adaptation unit; the thread compatible scheduling device is integrated in a back-end control device in the form of a computer program, comprising:

[0122] a construction module 300, configured to, after a task is created locally, control the language adaptation unit in the heterogeneous language module corresponding to the initiating language of the task according to the initiating language of 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 comprises context information of the corresponding task;

[0123] a receiving and maintaining module 400, configured to control the central scheduling unit to periodically receive and maintain thread resource state information from each of the heterogeneous language modules;

[0124] a decision module 500, configured to, after the central scheduling unit receives the task, control the central scheduling unit to make a scheduling decision for the task according to the task request data structure of the task and the thread resource state information, and determine a target heterogeneous language module;

[0125] a distribution module 600, configured to distribute the task to the language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined by the scheduling decision of the task;

[0126] a control and execution module 700, configured to, after the target heterogeneous language module receives the task, control the target heterogeneous language module to create an execution thread, bind the context information of the task to the life cycle of the execution thread, and execute the task through the execution thread;

[0127] a reporting module 800, configured to, after the task is executed, control the language adaptation unit in the target heterogeneous language module to report the execution result of the task to the central scheduling unit.

[0128] In some embodiments, the decision module 500 is configured 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 of the task and the thread resource state information when the central scheduling unit receives the task:

[0129] In some embodiments, the decision module 500 is configured to control the central scheduling unit to make a scheduling decision for the task and determine the target heterogeneous language module according to the function identifier, the initiating language, the priority, the estimated resource occupancy of the task and the thread resource state information when the central scheduling unit receives the task:

[0130] In some embodiments, the decision module 500 is configured to control the central scheduling unit to make a scheduling decision for the task and determine the target heterogeneous language module according to the function identifier, the initiating language, the priority, the estimated resource occupancy of the task and the thread resource state information when the central scheduling unit receives the task:

[0131] A1. If the thread resource of the heterogeneous language module corresponding to the initiating language is greater than or equal to the estimated resource occupancy of the task, the heterogeneous language module corresponding to the initiating language is considered to be resource sufficient, and the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module;

[0132] A2. If the thread resource of the heterogeneous language module corresponding to the initiating language is less than the estimated resource occupancy 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 considered to be resource insufficient, and according to the thread resource state information, other heterogeneous language modules whose thread resources are greater than or equal to the estimated resource occupancy of the task are selected and determined as the target heterogeneous language module;

[0133] A3. If the thread resource of the heterogeneous language module corresponding to the initiating language is less than the estimated resource occupancy 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 the task is added to the waiting queue of the target heterogeneous language module according to the priority of the task in the subsequent distribution step, and is executed in turn according to the waiting queue.

[0134] Please refer to Figure 4 , Figure 4A structural schematic diagram of an electronic device is provided for an embodiment of the present application. The present application provides an electronic device 13, comprising a processor 1301 and a memory 1302. The processor 1301 and the memory 1302 are interconnected and communicate with each other through a communication bus 1303 and / or other forms of connection mechanism (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 compatibility scheduling method in any optional implementation of the above-mentioned embodiments, so as to realize the following functions: after a task is created locally, according to an initiation language adopted by the task, a language adaptation unit in a heterogeneous language module corresponding to the initiation language is controlled to construct a task request data structure for the task, and the task request data structure is submitted to a central scheduling unit; the task request data structure comprises context information of the task; the central scheduling unit is controlled to periodically receive and maintain thread resource state 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 according to the task request data structure of the task and the thread resource state information, and determine a target heterogeneous language module; the task is distributed to the language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined by the scheduling decision of the task; after the target heterogeneous language module receives the task, the target heterogeneous language module is controlled to create an execution thread, bind the context information of the task to the life cycle of the execution thread, and execute the task 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.

[0135] The embodiment of the present application provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to perform the thread compatible scheduling method in any optional implementation manner of the above embodiment, so as to realize the following functions: after a task is created locally, according to an initiation language adopted by the task, a language adaptation unit in a heterogeneous language module corresponding to the initiation language is controlled to construct a task request data structure for the task, and the task request data structure is submitted to a central scheduling unit; the task request data structure comprises context information of the corresponding task; the central scheduling unit is controlled to periodically receive and maintain thread resource state 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 according to the task request data structure of the task and the thread resource state information, and determine a target heterogeneous language module; the task is distributed to the language adaptation unit of the target heterogeneous language module according to the target heterogeneous language module determined by the scheduling decision of the task; 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 an execution result of the task to the central scheduling unit.

[0136] The computer readable storage medium can be implemented by any type of volatile or nonvolatile storage device or 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 memory, flash memory, magnetic disk or optical disk.

[0137] In the embodiments of the present application, it should be understood that the disclosed apparatus and method can be implemented in other manners. The embodiments described above are merely exemplary, for example, the division of the units is only a logical function division, and there can be another division manner in actual implementation; for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections can be indirect couplings or communication connections through some interfaces, devices or units, and can be in electrical, mechanical or other forms.

[0138] In addition, the units described as separate components can or can not be physically separate, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. Some or all of the units can be selected according to actual needs to achieve the purposes of the embodiments of the present application.

[0139] In addition, the various functional modules in the various embodiments of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0140] In this article, the relationship terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0141] The above description is merely exemplary of the embodiments of the present application, and is not intended to limit the protection scope of the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A thread compatibility scheduling method applied to a multi-language hybrid system, characterized in that, The multi-language hybrid system comprises 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, a language adaptation unit in a heterogeneous language module corresponding to an initiating language adopted by the task is controlled to construct a task request data structure for the task according to the initiating language, and the task request data structure is submitted to the central scheduling unit; the task request data structure comprises context information of the corresponding task; The central scheduling unit is controlled to periodically receive and maintain thread resource state information from each of the heterogeneous language modules; After the central scheduling unit receives the task, the central scheduling unit is controlled to make a scheduling decision for the task according to the task request data structure of the task and the thread resource state information, and determine a target heterogeneous language module, specifically comprising the following steps A1-A3: A1. If thread resources of the heterogeneous language module corresponding to the initiating language are greater than or equal to an estimated resource occupancy of the task, the heterogeneous language module corresponding to the initiating language is regarded as resource sufficient, and the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module; A2. If thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource occupancy of the task, and a 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 regarded as resource nervous, and other heterogeneous language modules with thread resources greater than or equal to the estimated resource occupancy of the task are selected as the target heterogeneous language module according to the thread resource state information; A3. If thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource occupancy 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 the task is added to a waiting queue of the target heterogeneous language module in a subsequent distribution step according to a priority of the task, and is executed in turn according to the waiting queue; The task is distributed to a language adaptation unit of the target heterogeneous language module determined according to the scheduling decision of the task; After the target heterogeneous language module receives the task, the target heterogeneous language module is controlled to create an execution thread, and context information of the task is bound to a 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 an execution result of the task to the central scheduling unit.

2. The thread-compatible scheduling method of claim 1, wherein, The task request data structure further comprises a function identifier, an initiating language, a priority and an estimated resource occupancy of the corresponding task.

3. The thread-compatible scheduling method of claim 1, wherein, The thread resource state information comprises an active thread number, a maximum capacity of a thread pool and a current resource occupancy. The thread resource state information comprises an active thread number, a maximum capacity of a thread pool and a current resource occupancy.

4. The thread-compatible scheduling method of claim 1, wherein, Context information corresponding to a task binding on the execution thread is automatically destroyed after the end of the life cycle of the execution thread.

5. A multi-lingual hybrid system, characterized by, The multi-language hybrid system comprises a plurality of heterogeneous language modules and a central scheduling unit, each of the heterogeneous language modules being deployed with a corresponding language adaptation unit; The heterogeneous language module is configured to perform the following steps: After the task is created locally, a corresponding language adaptation unit is controlled according to an initiation language adopted 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 comprises context information of the corresponding task; The central scheduling unit is configured to perform the following steps: Periodically receive and maintain thread resource state information from each of the heterogeneous language modules; After receiving the task, a scheduling decision is made for the task according to the task request data structure of the task and the thread resource state information, and a target heterogeneous language module is determined, specifically comprising the following steps A1-A3: A1. If the thread resource of the heterogeneous language module corresponding to the initiation language is greater than or equal to the estimated resource occupancy of the task, the heterogeneous language module corresponding to the initiation language is considered to be resource sufficient, and the heterogeneous language module corresponding to the initiation language is determined as the target heterogeneous language module; A2. If the thread resource of the heterogeneous language module corresponding to the initiation language is less than the estimated resource occupancy 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 initiation language, the heterogeneous language module corresponding to the initiation language is considered to be resource stressed, and other heterogeneous language modules with thread resources greater than or equal to the estimated resource occupancy of the task are selected as the target heterogeneous language module according to the thread resource state information; A3. If the thread resource of the heterogeneous language module corresponding to the initiation language is less than the estimated resource occupancy 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 initiation language, the heterogeneous language module corresponding to the initiation language is determined as the target heterogeneous language module, so that the task is added to a waiting queue of the target heterogeneous language module in a subsequent distribution step according to the priority of the task, and is executed in turn according to the waiting queue; The task is distributed to the language adaptation unit of the target heterogeneous language module determined according to the scheduling decision of the task; 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 executed, the execution result of the task is reported to the central scheduling unit by controlling the corresponding language adaptation unit.

6. A thread compatibility scheduling apparatus applied to a multi-lingual mixed system, characterized by, The multi-language hybrid system comprises a plurality of heterogeneous language modules and a central scheduling unit, each of the heterogeneous language modules being deployed with a corresponding language adaptation unit; The thread-compatible scheduling device comprises: A constructing module, configured to, after a task is created locally, control a language adaptation unit in a heterogeneous language module corresponding to an initiating language of the task to construct a task request data structure for the task according to the initiating language, and submit the task request data structure to the central scheduling unit; the task request data structure comprises 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 state information from each of the heterogeneous language modules; A decision module, configured to, after the central scheduling unit receives the task, control the central scheduling unit to make a scheduling decision for the task according to the task request data structure of the task and the thread resource state information, and determine a target heterogeneous language module, specifically comprising the following steps A1-A3: A1. If thread resources of the heterogeneous language module corresponding to the initiating language are greater than or equal to an estimated resource occupancy of the task, the heterogeneous language module corresponding to the initiating language is regarded as resource sufficient, and the heterogeneous language module corresponding to the initiating language is determined as the target heterogeneous language module; A2. If thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource occupancy of the task, and a 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 regarded as resource nervous, and other heterogeneous language modules with thread resources greater than or equal to the estimated resource occupancy of the task are selected as the target heterogeneous language module according to the thread resource state information; A3. If thread resources of the heterogeneous language module corresponding to the initiating language are less than the estimated resource occupancy 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 the task is added to a waiting queue of the target heterogeneous language module according to a priority of the task in a subsequent distribution step, and is executed in turn according to the waiting queue; A distribution module, configured to, according to the target heterogeneous language module determined after the scheduling decision of the task, distribute the task to a language adaptation unit of the target heterogeneous language module; A control execution module, configured to, after the target heterogeneous language module receives the task, control the target heterogeneous language module to create an execution thread, and bind context information of the task to a life cycle of the execution thread, and execute the task through the execution thread; A reporting module, configured to, after the task is executed and completed, control the language adaptation unit in the target heterogeneous language module to report an execution result of the task to the central scheduling unit.

7. An electronic device, comprising: A processor and a memory, the memory stores computer readable instructions, when the computer readable instructions are executed by the processor, the steps in the thread compatible scheduling method in any one of claims 1-4 are run.

8. A computer-readable storage medium having stored thereon a computer program, characterized in that The computer program, when executed by a processor, runs the steps of the thread-compatible scheduling method according to any of claims 1-4.

Images