Multi-process shared information storage method and device, equipment, medium and vehicle

Abstract

The invention provides a multi-process shared information storage method and device, equipment, a medium and a vehicle. The method comprises the following steps: acquiring a process identifier corresponding to each process in a plurality of processes of a target application; for any first process in the multiple processes, under the condition that the target application is started, the process identifier corresponding to the first process is matched, shared information corresponding to the first process is obtained, the shared information corresponding to the first process comprises a first field and a second field, and the first fields corresponding to different processes are the same; acquiring a return address of the creation function under the condition of detecting that the first process completes creation of any first thread through the creation function; obtaining a preset in-stack function in the return address; and executing the stack-in function to replace the context environment in the first thread with shared information corresponding to the first process. According to the embodiment of the invention, the execution efficiency of the multi-process application can be improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a storage method, device, equipment, medium and vehicle for multi-process shared information. Background Art

[0002] The implementation of Multi-Process Service (MPS) on the embedded side requires pushing a shared context (SharedContext) into the thread stack of the Graphics Processing Unit (GPU). In the prior art, each process has its own independent context. The contexts between these processes are isolated, and there is no shared data or state between them. Therefore, when running a multi-process application, the GPU needs to call different processes one by one, resulting in low task execution efficiency of the multi-process application. Summary of the invention

[0003] The present application provides a method, device, equipment, medium and vehicle for storing multi-process shared information, which can improve the execution efficiency of multi-process applications.

[0004] In a first aspect, the present application provides a method for storing multi-process shared information, the method comprising:

[0005] Obtain the process ID corresponding to each of the multiple processes of the target application;

[0006] For any first process among the multiple processes, when the target application is started, the process identifier corresponding to the first process is matched to obtain shared information corresponding to the first process, where the shared information is used to coordinate data processing with multiple threads included in the first process, wherein the shared information corresponding to the first process includes a first field and a second field, and the first fields corresponding to different processes are the same;

[0007] When it is detected that the first process completes the creation of any first thread through the creation function, obtaining a return address of the creation function;

[0008] Get the stack function pre-set in the return address;

[0009] The push function is executed to replace the context environment in the first thread with the shared information corresponding to the first process.

[0010] In a second aspect, the present application provides a storage device for multi-process shared information, the device comprising:

[0011] A first acquisition module, used to acquire a process identifier corresponding to each process in multiple processes of a target application;

[0012] a matching module, configured to match a process identifier corresponding to any first process among the plurality of processes, when starting a target application, to obtain shared information corresponding to the first process, wherein the shared information is used to coordinate data processing with a plurality of threads included in the first process, wherein the shared information corresponding to the first process includes a first field and a second field, and the first fields corresponding to different processes are the same;

[0013] A second acquisition module is used to acquire a return address of a creation function when it is detected that the first process completes the creation of any first thread through a creation function;

[0014] The third acquisition module is used to acquire the stack function preset in the return address;

[0015] The execution module is used to execute the push function to replace the context environment in the first thread with the shared information corresponding to the first process.

[0016] In a third aspect, the present application provides an electronic device, the device comprising: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the storage method for implementing the above-mentioned multi-process shared information

[0017] In a fourth aspect, the present application provides a computer-readable storage medium having computer program instructions stored thereon, which implement the above-mentioned method for storing multi-process shared information when the computer program instructions are executed by a processor.

[0018] In a fifth aspect, an embodiment of the present application further provides a vehicle, the vehicle comprising at least one of the following:

[0019] A storage device for multi-process shared information as in the second aspect;

[0020] Such as the electronic device of the third aspect;

[0021] A computer-readable storage medium as in the fourth aspect.

[0022] The storage method, device, equipment, medium and vehicle for multi-process shared information of the embodiments of the present application obtain the process identifier corresponding to each process in the multiple processes of the target application; for any first process in the multiple processes, when the target application is started, the process identifier corresponding to the first process is matched to obtain shared information corresponding to the first process, and the shared information is used to coordinate data processing by multiple threads included in the first process, wherein the shared information corresponding to the first process includes a first field and a second field, and the first fields corresponding to different processes are the same; when it is detected that the first process completes the creation of any first thread by creating a function, the return address of the creation function is obtained; the stack function pre-set in the return address is obtained; and the stack function is executed to replace the context environment in the first thread with the shared information corresponding to the first process. Through the above method, the first fields corresponding to different processes in the target application are the same, and when the first process creates a new thread by creating a function, the context environment in the first thread is replaced with a shared context environment (i.e., shared information) by executing a preset push function, ensuring that all threads can share the same context environment (i.e., the same field) during runtime, replacing the traditional practice of each thread having an independent context environment, so that multiple processes of the target application can be executed in parallel without interfering with each other, thereby improving the execution efficiency of multi-process applications. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] In order to more clearly illustrate the technical solution of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0024] Figure 1 It is a flowchart of a method for storing multi-process shared information provided by an embodiment of the present application;

[0025] Figure 2 This is a schematic diagram of an implementation flow of a class constructor provided in an embodiment of the present application;

[0026] Figure 3 This is a flowchart of a function creation implementation provided by an embodiment of the present application;

[0027] Figure 4 This is a flowchart of a stacking function implementation provided by an embodiment of the present application;

[0028] Figure 5 It is a structural diagram of a storage device for multi-process shared information provided in an embodiment of the present application;

[0029] Figure 6 It is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0030] In order to more clearly understand the above-mentioned purposes, features and advantages of the present application, the scheme of the present application will be further described below. It should be noted that the embodiments of the present application and the features in the embodiments can be combined with each other without conflict.

[0031] In the following description, many specific details are set forth to facilitate a full understanding of the present application, but the present application may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only part of the embodiments of the present application, rather than all of the embodiments.

[0032] It should be noted that, in this article, relational 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. Moreover, the term "comprising" or any other variant thereof is intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprising a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0033] The implementation of MPS on the embedded side requires pushing a shared context (SharedContext) into the thread stack using the GPU. In the prior art, in order to ensure that each thread using the GPU executes the push operation of the shared context when the thread is created, there are two common methods: one is to execute the push operation of the Shared Context as soon as possible at the entry function of creating the thread in the code; the other is to uniformly execute the push operation of the Shared Context at the middleware layer.

[0034] However, both of these traditional push methods have their own shortcomings. The first method has the disadvantage that it is difficult to fully cover the push operation of each newly created thread in the project code. Even if the code is designed carefully, there will still be implicit thread creation, and this implicit thread creation is difficult to detect and sometimes difficult to avoid, such as calling a common application programming interface (Application Programming Interface, API), which implicitly creates a thread. In addition, this method has an obvious disadvantage of poor scalability and high maintenance cost. For example, when adding, adjusting or deleting a function in the original project, the adjusted code needs to be carefully tested to ensure that the newly introduced thread has correctly executed the push operation of Shared Context. When a new application (Application, APP) using GPU is added, the project not only inherits the MPS-related code, but also inevitably executes the push operation of Shared Context for each thread, which has poor scalability. The disadvantages of the second method are: first, you need to have a set of self-developed middleware or purchase customizable middleware, otherwise you cannot realize the corresponding function; if you already have a set of mature middleware software available, in order to realize the thread push into Shared Context operation, you must modify the middleware software, and this change often involves many users, which can be said to be a domino effect. The result is not only a long development and testing cycle, but also that each business party using the middleware may also need to re-adapt the new middleware interface, which is a high overall cost. In general, the above two methods have obvious disadvantages, making the launch cost of MPS functions high.

[0035] In order to solve the problems of the prior art, the embodiments of the present application provide a method, device, equipment, medium and vehicle for storing multi-process shared information. The method for storing multi-process shared information provided by the embodiments of the present application is first introduced below.

[0036] Figure 1 FIG. 1 is a flow chart showing a method for storing multi-process shared information provided by an embodiment of the present application. Figure 1 As shown, the storage method of the multi-process shared information may include the following steps:

[0037] S100, obtaining a process identifier corresponding to each process in a plurality of processes of a target application.

[0038] Optionally, in a possible implementation of the present application, the process (Client) first generates a device key (Device Key), which may be randomly generated or generated according to a certain protocol. Then, the Client sends the key to the server (Server). After receiving the Device Key sent by the Client, the server uses a key negotiation protocol to generate a process identifier (i.e., a shared key) corresponding to the process.

[0039] Optionally, in another possible implementation of the present application, for the MPS, each time an application is started, an initialization operation of the MPS is performed, and the initialization operation can directly communicate with the server to obtain a process identifier corresponding to each process.

[0040] S200, for any first process among multiple processes, when starting the target application, match the process identifier corresponding to the first process to obtain shared information corresponding to the first process, where the shared information is used to coordinate data processing with multiple threads included in the first process, wherein the shared information corresponding to the first process includes a first field and a second field, and the first field corresponding to different processes is the same.

[0041] Optionally, in an embodiment of the present application, the shared information may include the running information of the target application. The shared context environment may include register status, memory status, instruction address, in short, the program site status before switching the context environment. Specifically, the shared context environment may refer to a collection of data, variables, status and other resources that are commonly accessed by multiple processes in a multi-process application. For example, these shared data and information may be the status, configuration, cache, global variables, etc. of the application when it is running. The shared information environment provides a mechanism for exchanging and sharing data between multiple threads in multiple processes, so that multiple threads can work together to complete tasks together.

[0042] Optionally, in a possible implementation of the present application, the first field may be a context environment shared between each process, and the second field may be data for identifying different processes, for example, may be identifiers of different processes.

[0043] Optionally, in a possible implementation of the present application, the identities of different processes or threads can be identified and verified through a unified computing device architecture (Compute Unified Device Architecture, CUDA) toolkit and a GPU driver. The CUDA API is then called to create shared information (i.e., Shared Context). This API may require the process identifier (i.e., Shared Key) to be passed in as a parameter. The CUDA API then uses the received process identifier to verify and create shared information. If the process identifier is valid and passes the verification, the CUDA API will create a shared information that will be associated with the current process. Once the shared information is created, the shared information can be used in the thread to perform GPU tasks. GPU resources can thus be shared between processes and each thread without having to reinitialize the GPU environment each time. And multiple processes or threads work together on the GPU to share GPU resources, thereby improving the performance and efficiency of the application.

[0044] Optionally, in these optional embodiments, these steps ensure that multiple threads work together in a shared context environment, thereby improving the execution efficiency of multi-threaded applications.

[0045] S300, when it is detected that the first process completes the creation of any first thread through a creation function, obtaining a return address of the creation function, where the creation function is used to create a thread.

[0046] Optionally, in an embodiment of the present application, in a multi-process application, the creation of a thread is completed by calling a creation function (such as pthread_create()). Normally, the creation function will return before the new thread starts executing, that is, before the new thread executes. Therefore, the completion of thread creation can be detected at a certain point in time. Once the thread creation is detected to be completed, the return address of the creation function can be obtained. The return address of the creation function is a pointer to the function call location, which indicates where to continue executing the code of the main thread. By obtaining this return address, the call location of the creation function can be obtained, thereby obtaining the return address of the creation function.

[0047] Optionally, in a possible implementation of the present application, the return address of the creation function can be obtained using the debugging and tracing tools or APIs provided by the operating system. For example, the function in the debug library can be used to obtain the function call stack information, from which the return address of the creation function can be obtained. It should be noted that the specific implementation may vary depending on the operating system and programming language.

[0048] S400, obtaining the stack push function preset in the return address.

[0049] Optionally, in an embodiment of the present application, in the MPS system, when a function is called, the return address of the function will be saved in the stack. The return address refers to the address where the program will continue to execute after the function is executed. Through the return address, the execution function of the return address can be set to a predefined push function, which is used to push shared information into the newly created thread.

[0050] S500, executing a stacking function to replace the context environment in the first thread with the shared information corresponding to the first process

[0051] Optionally, in an embodiment of the present application, a push function can be called through a function pointer, and when calling the push function, shared information can be passed to the push function as a parameter. The shared information contains the context environment required for data processing by multiple threads of the collaborative target application. The push function will then perform an operation of replacing the context environment of the current thread with the shared information based on the shared information passed. This may involve replacing register values, stack contents, etc. accordingly. Once the push function is executed, the context environment stored in the first thread will be replaced with the shared information corresponding to the first process. Afterwards, when the first thread performs any operation, the context environment in the shared information corresponding to the first process, i.e., the first field, will be used.

[0052] In the storage method of multi-process shared information provided in an embodiment of the present application, the process identifier corresponding to each process of the multiple processes of the target application is obtained; for any first process among the multiple processes, when the target application is started, the process identifier corresponding to the first process is matched to obtain shared information corresponding to the first process, and the shared information is used to coordinate data processing by multiple threads included in the first process, wherein the shared information corresponding to the first process includes a first field and a second field, and the first fields corresponding to different processes are the same; when it is detected that the first process completes the creation of any first thread by creating a function, the return address of the creation function is obtained; the stack function pre-set in the return address is obtained; and the stack function is executed to replace the context environment in the first thread with the shared information corresponding to the first process. Through the above method, the first fields corresponding to different processes in the target application are the same, and when the first process creates a new thread by creating a function, the context environment in the first thread is replaced with a shared context environment (i.e., shared information) by executing a preset push function, ensuring that all threads can share the same context environment (i.e., the same field) during runtime, replacing the traditional practice of each thread having an independent context environment, so that multiple processes of the target application can be executed in parallel without interfering with each other, thereby improving the execution efficiency of multi-process applications.

[0053] In one embodiment, the above step 200 may specifically perform the following steps:

[0054] S210, when starting the target application, based on a preset matching rule, obtain shared information of a process identifier corresponding to the first process from a pre-acquired correspondence relationship, wherein the correspondence relationship includes multiple process identifiers and shared information corresponding to the multiple process identifiers.

[0055] Optionally, in an embodiment of the present application, when starting the target application, the process identifier of the first process is obtained. This can usually be done through a system call or a library function. Then, based on a preset matching rule, the process identifier of the first process is matched with the pre-acquired correspondence. For example, a mapping table, a configuration file, or other data structure can be used to store the correspondence between the process identifier and the shared information. Once the match is successful, the shared information corresponding to the first process will be obtained. This information should include a first field and a second field, and the first field has the same value between different processes. These shared information will help the threads in each process share the context environment and improve the execution efficiency of multi-process applications.

[0056] Specifically, first, the mapping relationship between the application identifier and the shared context environment can be pre-set in the system configuration, or dynamically specified through configuration files, databases, etc. When the application starts, the corresponding database is dynamically loaded according to the mapping relationship of the application identifier. For example, the dynamic library loading function can be used to load the database into the application at runtime. Once the database is loaded successfully, the interface defined in the database can be called to obtain the shared information corresponding to different processes. After obtaining the shared information, the shared information can be initialized. This may involve operations such as memory allocation, data loading, and state initialization.

[0057] Optionally, in another possible implementation of the present application, as Figure 2As shown, the MPSGuard class constructor can be constructed, and the MPSGuard class constructor contains the implementation logic of the entire MPS client. Specifically, the execution logic of the MPSGuard class constructor is: first, the name of the symbolic link path (i.e., application) of the current application is obtained, and it is determined whether it is a call of some applications that come with the system. If it is a call thread of a system tool, it is directly skipped because it is an independent application and does not involve GPU operations. Otherwise, the thread_start_prehook function (i.e., stack function) is registered for the current application. The function is used to execute the key to push the thread into the Shared Context operation. Then the MPS initialization operation is executed, that is, the MPS client communicates with the server to obtain the SharedKey (i.e., process identifier), and then creates the Shared Context (shared information). Since the static global variable initialization is completed before the main function is executed, the operation of pushing all threads created by the application that loads the software development kit (Software Development Kit, SDK) with the MPSGuard class constructor into the Shared Context can be completely covered, and there will be no situation where the implicit creation of threads is missed.

[0058] Optionally, in an embodiment of the present application, by processing thread creation in the constructor, it is ensured that each thread can be correctly pushed into the Shared Context, whether it is an explicitly created thread or an implicitly created thread, thereby ensuring the normal use of the MPS function. And the application does not need to explicitly integrate MPS-related code, it only needs to load the SDK with the MPSGuard class constructor, thereby reducing the maintenance cost of the business engineering code. When a new application that needs to use the GPU is added, there is no need to modify the business code, but automatically obtain the MPS features, which improves scalability and adaptability. And there is no need to modify the middleware, avoiding the complexity of development and maintenance. By processing thread creation and Shared Context operations in the constructor, a more convenient, efficient and unified way is provided to implement GPU context sharing in multi-threaded applications, thereby optimizing the performance and development process of the application.

[0059] Optionally, in these optional embodiments, for some application tools that come with the system, it is not necessary to use the GPU or involve a shared context environment. By skipping the processing of these tools, unnecessary resource consumption can be avoided or reduced, system resources can be saved, and overall efficiency and performance can be improved. By executing the push function only on the application program in need, it can be ensured that only those applications involving GPU operations or requiring a shared context environment are affected. This helps to accurately apply functions and avoid or reduce the introduction of additional logic on unnecessary applications. By selectively applying the push function, the controllability of the system can be improved. This means that threads will only be operated when they are really needed, avoiding modification and registration of all applications, reducing the probability of errors, reducing unnecessary operations and performance losses, and optimizing overall system performance and efficiency.

[0060] In one embodiment, the above step 300 may specifically perform the following steps:

[0061] S310, monitoring the calling status of the creation function through the monitoring function.

[0062] Optionally, in a possible implementation of the present application, by monitoring functions, for example, by intercepting system calls or hooking functions, the calling of functions created in the target application can be monitored in real time. Specifically, this can be achieved by recording the parameters, return values, and context information of the function call, so that subsequent steps can be analyzed and judged.

[0063] S320: When the calling situation indicates that the creation function is called by the first process, determine that the target application completes the creation of the current thread through the creation function.

[0064] Optionally, in an embodiment of the present application, when monitoring the creation function being called, its parameters and context information can be analyzed to determine whether it is a call of the first process to create a new thread. Specifically, it can be determined whether it is a thread creation of the first process by checking the parameters, the context of the function call and other relevant information.

[0065] S330, obtaining the return address of the creation function through the monitoring function.

[0066] Optionally, in an embodiment of the present application, after confirming that the first process has completed the creation of the current thread by creating a function, the return address of the creation function can be obtained from the monitoring record. This return address indicates that the new thread is about to start executing. Based on the return address of the creation function, the entry function of the new thread can be located. By replacing the address of the push function with the storage address of the thread entry function, the purpose of executing the push function before the new thread starts executing is achieved. In this way, each time a new thread is created, the push function will be executed first, the context environment of the first thread will be replaced with the shared information, and then the original thread entry function will be executed, so that the shared information is applied to the execution task of the new thread.

[0067] Optionally, in a possible implementation of the present application, as Figure 3 As shown, any newly created thread will automatically call the pthread_create function (i.e., the creation function) provided by the system. By using this mechanism, it is only necessary to capture the call of the pthread_create function and replace it with a custom implementation, so that the custom logic can be automatically executed when the thread is created. For example, the operation of pushing the Shared Context into the thread in the thread_start_prehook function (i.e., the push function) will be automatically executed in this application. Specifically, in the implementation of the pthread_create function, an object is first instantiated to store some parameters, including the thread entry function, the entry function parameters, etc. Then the monitoring function (e.g., dlsym) is called to capture the runtime address returned by the system pthread_create function. The address was originally used to execute the thread entry function. Based on the returned runtime address, the embodiment of the present application replaces the default thread entry function with the push function, thereby achieving the purpose of executing the thread_start_prehook function, and finally executing the default thread entry function to ensure that the thread default function is not affected.

[0068] In these optional embodiments, through the implementation of the stack function, and the replacement of the default thread entry function, the self-defined logic can be automatically embedded into the starting stage of each newly created thread, thereby realizing the automatic initialization of the thread, so that the developer does not need to manually insert specific logic code at each thread creation place, because the logic has been encapsulated in the self-defined pthread_create function (i.e., the creation function) implementation. This reduces the risk of errors and omissions. Through the self-defined pthread_create function, the self-defined logic is executed when the thread is created, such as the operation of pressing SharedContext into the thread. This ensures that each thread will perform the same initialization steps when it is created, thereby ensuring that the shared context environment is properly set in each thread. Concentrating the complex initialization logic in the self-defined pthread_create function helps to improve the maintainability of the code. The developer can manage and adjust the logic of thread initialization in one place, without having to find and modify the code at each thread creation place in the entire code base.

[0069] And new thread creation does not require additional integration steps or specific calls. Just call the system-provided pthread_create function, and the logic will be automatically applied to the new thread. After replacing the default thread entry function, even if custom logic is added, it can ensure that the default functions of the thread (such as task execution) are not affected. In summary, by automatically executing custom logic when a thread is created, the thread initialization process can be simplified, the maintainability and consistency of the code can be improved, and the workload of developers can be reduced.

[0070] In one embodiment, after the above step 500, the method may further specifically perform the following steps:

[0071] S600, when the push function is executed, calling a thread entry function corresponding to the first thread, where the thread entry function includes a data processing task of the first thread.

[0072] S700, executing a thread entry function to enable a first thread to execute a data processing task.

[0073] Optionally, in an embodiment of the present application, first, wait for the stack function (thread_start_prehook) to be executed to ensure that the shared information has been loaded into the first thread. Then, after the stack function is executed, call the thread entry function of the current thread. In the thread entry function, perform the data processing task of the first thread. This can be any specific task, such as calculation, data processing, algorithm execution, etc.

[0074] In these optional embodiments, after the push function (thread_start_prehook) is executed, the thread entry function is called to ensure that the thread loads the shared information before executing the actual task. The shared information has been loaded into the context environment of the first thread in the push function, which enables the thread to easily access shared data and resources when executing the actual data processing task without additional context switching. This can optimize the collaborative processing and communication of multi-threaded applications. By loading shared information during the thread creation process, threads can more efficiently collaborate to process data, reduce the overhead of context switching, and thus improve the performance of the entire application. It is suitable for scenarios where frequent data sharing and collaborative processing are required.

[0075] Optionally, in the embodiment of the present application, the MPS client function is implemented by capturing threads and setting environment variables, which not only has low development and maintenance costs, but also has high flexibility and scalability. And by capturing threads and setting environment variables to achieve full coverage of thread push operations into Shared Context, the project implementation becomes simple; and since each business APP does not need to maintain a set of MPS client code separately, the code and function can be unified, which is easy to maintain; since the MPS features are independent of the business APP, the scalability and flexibility of the entire system are greatly increased, so that one-time development and multiple uses can be achieved.

[0076] In one embodiment, the creation function is also used to instantiate a storage object, which includes at least one of a thread entry function and an entry function parameter, and the entry function parameter is used to provide the thread entry function with parameter information required for the data processing task.

[0077] Optionally, in an embodiment of the present application, when a new thread needs to be created, a creation function (such as a pthread_create function) provided by the system is called to implement it. The call of this creation function usually involves passing a thread entry function and entry function parameters. Inside the creation function, in addition to creating a new thread, a storage object is also instantiated. The purpose of this storage object is to store information such as the thread entry function and entry function parameters for use in subsequent steps to ensure that the thread can perform the correct data processing task. The storage object is usually passed as a parameter to the newly created thread to ensure that the thread can access the correct thread entry function and entry function parameters when executing, thereby helping to ensure that each thread performs the correct data processing task and can obtain the required parameter information.

[0078] Optionally, in an embodiment of the present application, the storage object may include a thread entry function, entry function parameters, and a hook function (prehook function), wherein the thread entry function is a specific function that represents the starting point of a new thread. When a new thread is created and starts executing, the new thread will start executing code from the thread entry function. The thread entry function defines the behavior of the new thread, that is, the task running on the thread. Each thread must specify a thread entry function. The entry function parameters are parameters passed to the thread entry function. These parameters can be any data and are usually used to provide the thread with necessary information so that the thread can access the required data when executing the task. The entry function parameters can be pointers, structures, basic data types, etc. The prehook function is a predefined function that is usually executed before the thread is created. Its function is to perform some preprocessing operations before the thread actually starts executing. In the present application, the prehook function is used to execute the thread push into the Shared Context operation, that is, the stack function, which associates the thread with the shared context to realize multi-threaded collaborative data processing. By instantiating the ThreadStartParam object and storing the thread entry function, entry function parameters, and prehook function, it is ensured that all necessary information can be correctly transmitted and used during the thread creation and execution process, thereby realizing multi-threaded cooperative processing.

[0079] In one embodiment, the above step 500 may specifically perform the following steps:

[0080] S510, obtaining the initialization status of the first thread through a push function, where the initialization status is used to indicate whether the initialization operation of the unified computing device architecture CUDA is completed, and CUDA is used to run the target application;

[0081] S520, when the initialization status indicates that the CUDA has completed the initialization operation, obtaining a data identifier of the context environment stored in the first thread;

[0082] S530: When the data identifier does not match the process identifier corresponding to the first process, replace the context environment in the first thread with the shared information corresponding to the first process.

[0083] Optionally, in a possible implementation of the present application, a push function is executed to obtain the initialization status of the unified computing device architecture (Compute Unified Device Architecture, CUDA). The initialization status here is used to indicate whether CUDA has completed the initialization operation. CUDA is a unified computing device architecture for performing GPU computing, and initialization is to ensure that CUDA is ready before running the target application. If the initialization status indicates that CUDA has completed the initialization operation, then the data identifier of the context environment stored in the first thread will be obtained next. This data identifier may be an identifier for uniquely identifying the context environment in which the thread is located. And when the data identifier matches the process identifier corresponding to the first process, it means that the context environment of the first thread is shared information, so there is no need to replace the context environment. If the data identifier does not match the process identifier corresponding to the first process, this may mean that the context environment of the current thread is not shared information, and the context environment needs to be replaced. Therefore, when the data identifier does not match the process identifier corresponding to the first process, the context environment in the first thread will be replaced with the shared information corresponding to the first process to ensure that the thread can correctly use the shared context environment for data processing.

[0084] Optionally, in another possible implementation of the present application, as Figure 4 As shown, the specific execution flow of the push function can be: first determine whether the current Shared Context (i.e., shared information) has been created. If the Shared Context has not been created, then return directly; if the Shared Context has been created, then obtain the Context (context environment) in the current thread. If an error code indicating that CUDA has not been initialized is obtained, then perform CUDA initialization, otherwise there is no need to perform CUDA initialization again. Then determine whether the Context in the current thread is a Shared Context. If not, perform the push operation into the Shared Context, otherwise skip. The thread_start_prehook function (i.e., the push function) executes the logic inside the function each time a new thread is created, thereby ensuring that each newly created thread, whether it is explicitly created in the project code or implicitly created by calling certain APIs, can be pushed into the Shared Context.

[0085] In these optional embodiments, it is determined whether shared information (Shared Context) has been created currently to ensure that the shared information of the thread is only created once, avoid repeated creation, and reduce resource waste. It is determined whether the context environment of the current thread is shared information. If it is not shared information, the push operation of Shared Context is performed. In this way, whether the thread is created explicitly or implicitly, it can be ensured that the thread is correctly pushed into the shared context environment, and the unified management and use of shared information is realized. The thread_start_prehook function (stack function) is executed each time a new thread is created, ensuring that the thread is pushed into the shared context environment according to the specified logic when any thread is created. The reliability of the code is improved, ensuring that the shared information can be used correctly in all threads, and the correctness and effectiveness of the shared context environment are guaranteed, thereby improving the stability and performance of multi-threaded applications.

[0086] Optionally, in the embodiment of the present application, the overall design and implementation idea is to encapsulate the operations of creating Shared Context and pushing Shared Context into threads into a class constructor, and globally statically initialize the object. The entire project code is packaged as an SDK and built into a .so file, and used in conjunction with the LD_PRELOAD environment variable, thereby achieving the correct execution of Shared Context creation, thread capture, and thread push into Shared Context operations, ensuring the correct use of the MPS function. The operation of pushing threads into SharedContext is achieved by capturing threads and loading dynamic libraries through environment variables.

[0087] In these optional embodiments, the operation of pressing all newly created threads into the Shared Context can be covered by thread capture, thereby ensuring the normal use of the MPS function and improving the model reasoning performance. Second, each business APP of MPS does not need to integrate MPS-related code (the implementation code related to the MPS features is foreign code to each business APP rather than part of their functions), so that the business functions and optimization features are independent. Since there is no need to maintain the same code segment in each business engineering code, unification is achieved and maintenance costs are greatly reduced. Third, when a new APP that needs to use the GPU is added, the MPS features can be used without any adaptation modification of the business code, and the scalability is greatly improved. Fourth, the embodiments of the present application will not involve modifications to the middleware, and the development cycle and maintenance costs are greatly improved.

[0088] Optionally, in an embodiment of the present application, the present application only needs to maintain a separate set of software to implement the three main key logics in the solution, without having to perform the operation of pushing the Shared Context at the thread creation point in each engineering code, thereby avoiding code confusion and reducing development workload. The adaptation of the business APP code to the MPS code during the development, function changes, etc. is avoided or reduced, and the business code and functional characteristics are separated, which is convenient for their respective maintenance and has low maintenance costs. This is reflected in the fact that if a new business APP using the GPU is connected, the MPS features can be used directly without additional development work, and the scalability is strong.

[0089] Based on the method for storing multi-process shared information provided in the above embodiment, the present application also provides an embodiment of a device for storing multi-process shared information.

[0090] Figure 5 A schematic diagram of the structure of a storage device for multi-process shared information provided by another embodiment of the present application is shown. For ease of explanation, only the parts related to the embodiment of the present application are shown.

[0091] Reference Figure 5 , the storage device for multi-process shared information may include:

[0092] A first acquisition module 501 is used to acquire a process identifier corresponding to each process in multiple processes of a target application;

[0093] A matching module 502 is used for matching a process identifier corresponding to any first process among the multiple processes when starting a target application, and obtaining shared information corresponding to the first process, wherein the shared information is used to coordinate data processing with multiple threads included in the first process, wherein the shared information corresponding to the first process includes a first field and a second field, and the first fields corresponding to different processes are the same;

[0094] The second acquisition module 503 is used to acquire the return address of the creation function when it is detected that the first process completes the creation of any first thread through the creation function;

[0095] The third acquisition module 504 is used to acquire the stack function preset in the return address;

[0096] The execution module 505 is used to execute the push function to replace the context environment in the first thread with the shared information corresponding to the first process.

[0097] In some embodiments, the matching module 502 may include:

[0098] The first acquisition submodule is used to obtain the shared information of the process identifier corresponding to the first process from the pre-acquired correspondence relationship based on the preset matching rule when starting the target application, and the correspondence relationship includes multiple process identifiers and shared information corresponding to the multiple process identifiers.

[0099] In some embodiments, the second acquisition module 503 may include:

[0100] The first monitoring submodule is used to monitor the calling status of the creation function through the monitoring function;

[0101] A first determining submodule is used to determine that the first process has completed the creation of the first thread through the creation function when the calling situation indicates that the creation function is called by the first process;

[0102] The second acquisition submodule is used to acquire the return address of the creation function through the monitoring function.

[0103] In some embodiments, the storage device for multi-process shared information may further include:

[0104] A calling module, used for calling a thread entry function corresponding to the first thread when the push function is executed, wherein the thread entry function includes a data processing task of the first thread;

[0105] The second execution module is used to execute the thread entry function to enable the first thread to perform the data processing task.

[0106] In some embodiments, the creation function is also used to instantiate a storage object, which includes at least one of a thread entry function and an entry function parameter, and the entry function parameter is used to provide the thread entry function with parameter information required for the data processing task.

[0107] In some embodiments, the execution module 505 may include:

[0108] A third acquisition submodule is used to acquire the initialization status of the first thread through a stack function, where the initialization status is used to indicate whether the unified computing device architecture CUDA has completed the initialization operation, and CUDA is used to run the target application;

[0109] A fourth acquisition submodule, configured to acquire a data identifier of the context environment stored in the first thread when the initialization condition indicates that the CUDA has completed the initialization operation;

[0110] The replacement submodule is used to replace the context environment in the first thread with the shared information corresponding to the first process when the data identifier does not match the process identifier corresponding to the first process.

[0111] It should be noted that the information interaction, execution process, etc. between the above-mentioned devices / units are based on the same concept as the method embodiment of the present application, and are devices corresponding to the above-mentioned battery thermal runaway warning method. All implementation methods in the above-mentioned method embodiment are applicable to the embodiments of the device. Its specific functions and technical effects can be found in the method embodiment part, which will not be repeated here.

[0112] The technicians in the relevant field can clearly understand that for the convenience and simplicity of description, only the division of the above-mentioned functional units and modules is used as an example for illustration. In practical applications, the above-mentioned function allocation can be completed by different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiment can be integrated in a processing unit, or each unit can exist physically separately, or two or more units can be integrated in one unit. The above-mentioned integrated unit can be implemented in the form of hardware or in the form of software functional units. In addition, the specific names of the functional units and modules are only for the convenience of distinguishing each other, and are not used to limit the scope of protection of this application. The specific working process of the units and modules in the above-mentioned system can refer to the corresponding process in the aforementioned method embodiment, which will not be repeated here.

[0113] Figure 6 A schematic diagram of the hardware structure of a battery cell thermal runaway warning rule generation device provided in an embodiment of the present application is shown.

[0114] The device may include a processor 601 and a memory 602 storing program instructions.

[0115] When the processor 601 executes the program, the steps in any of the above method embodiments are implemented.

[0116] Exemplarily, the program may be divided into one or more modules / units, one or more modules / units are stored in the memory 602 and executed by the processor 601 to complete the present application. One or more modules / units may be a series of program instruction segments capable of completing a specific function, and the instruction segments are used to describe the execution process of the program in the device.

[0117] Specifically, the processor 601 may include a central processing unit (CPU), or an application specific integrated circuit (ASIC), or may be configured to implement one or more integrated circuits of the embodiments of the present application.

[0118] The memory 602 may include a large capacity memory for data or instructions. By way of example and not limitation, the memory 602 may include a hard disk drive (HDD), a floppy disk drive, a flash memory, an optical disk, a magneto-optical disk, a magnetic tape, or a universal serial bus (USB) drive or a combination of two or more of these. In appropriate cases, the memory 602 may include a removable or non-removable (or fixed) medium. In appropriate cases, the memory 602 may be inside or outside the integrated gateway disaster recovery device. In a specific embodiment, the memory 602 is a non-volatile solid-state memory.

[0119] The memory may include read-only memory (ROM), random access memory (RAM), magnetic disk storage media devices, optical storage media devices, flash memory devices, electrical, optical or other physical / tangible memory storage devices. Thus, typically, the memory includes one or more tangible (non-transitory) readable storage media (e.g., memory devices) encoded with software including computer executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the method according to one aspect of the present application.

[0120] The processor 601 implements any one of the methods in the above embodiments by reading and executing program instructions stored in the memory 602 .

[0121] In one example, the electronic device may further include a communication interface 603 and a bus 610. The processor 601, the memory 602, and the communication interface 603 are connected via the bus 610 and communicate with each other.

[0122] The communication interface 603 is mainly used to implement communication between various modules, devices, units and / or equipment in the embodiments of the present application.

[0123] Bus 610 includes hardware, software or both, and the parts of online data flow billing equipment are coupled to each other. For example, but not limitation, bus may include accelerated graphics port (AGP) or other graphics bus, enhanced industrial standard architecture (EISA) bus, front-end bus (FSB), hypertransport (HT) interconnection, industrial standard architecture (ISA) bus, infinite bandwidth interconnection, low pin count (LPC) bus, memory bus, micro channel architecture (MCA) bus, peripheral component interconnection (PCI) bus, PCI-Express (PCI-X) bus, serial advanced technology attachment (SATA) bus, video electronics standard association local (VLB) bus or other suitable bus or two or more of these combinations. In appropriate cases, bus 610 may include one or more buses. Although the present application embodiment describes and shows a specific bus, the present application considers any suitable bus or interconnection.

[0124] In addition, in combination with the method in the above embodiment, the embodiment of the present application can provide a storage medium for implementation. The storage medium stores program instructions; when the program instructions are executed by a processor, any one of the methods in the above embodiment is implemented.

[0125] An embodiment of the present application further provides a chip, which includes a processor and a communication interface, wherein the communication interface and the processor are coupled, and the processor is used to run programs or instructions to implement the various processes of the above-mentioned method embodiment, and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0126] It should be understood that the chip mentioned in the embodiments of the present application can also be called a system-level chip, a system chip, a chip system or a system-on-chip chip, etc.

[0127] An embodiment of the present application provides a computer program product, which is stored in a storage medium. The program product is executed by at least one processor to implement the various processes of the above-mentioned method embodiment and can achieve the same technical effect. To avoid repetition, it will not be repeated here.

[0128] It should be clear that the present application is not limited to the specific configuration and processing described above and shown in the figures. For the sake of simplicity, a detailed description of the known method is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present application is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present application.

[0129] The functional modules shown in the above block diagram can be implemented as hardware, software, firmware or their combination. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (ASIC), suitable firmware, a plug-in, a function card, etc. When implemented in software, the elements of the present application are programs or code segments that are used to perform the required tasks. Programs or code segments can be stored in machine-readable media, or transmitted on a transmission medium or a communication link by a data signal carried in a carrier wave. "Machine-readable media" can include any medium that can store or transmit information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (RF) links, etc. Code segments can be downloaded via computer grids such as the Internet, intranets, etc.

[0130] It should also be noted that the exemplary embodiments mentioned in this application describe some methods or systems based on a series of steps or devices. However, this application is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiment, or in a different order from the embodiment, or several steps can be performed simultaneously.

[0131] The present application is described above with reference to the flowchart and / or block diagram of the method, device (system) and program product according to the embodiment of the present application.It should be understood that each square block in the flowchart and / or block diagram and the combination of each square block in the flowchart and / or block diagram can be realized by computer program instructions.These program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that these instructions executed by the processor of a computer or other programmable data processing device enable the realization of the function / action specified in one or more square blocks of the flowchart and / or block diagram.Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor or a field programmable logic circuit.It can also be understood that each square block in the block diagram and / or flowchart and the combination of the square blocks in the block diagram and / or flowchart can also be realized by the dedicated hardware that performs the specified function or action, or can be realized by the combination of dedicated hardware and computer instructions.

[0132] The above are only specific implementation methods of the present application. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, modules and units described above can refer to the corresponding processes in the aforementioned method embodiments, and will not be repeated here. It should be understood that the protection scope of the present application is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed in this application, and these modifications or replacements should be included in the protection scope of this application.

Claims

1. A method for storing multi-process shared information, characterized in that: The method comprises: Obtain the process ID corresponding to each of the multiple processes of the target application; For any first process among the multiple processes, when the target application is started, a process identifier corresponding to the first process is matched to obtain shared information corresponding to the first process, wherein the shared information is used to coordinate data processing with multiple threads included in the first process, wherein the shared information corresponding to the first process includes a first field and a second field, and the first fields corresponding to different processes are the same; When it is detected that the first process completes the creation of any first thread through the creation function, obtaining a return address of the creation function; Obtaining a stack function preset in the return address; The push function is executed to replace the context environment in the first thread with the shared information corresponding to the first process.

2. The method according to claim 1, characterized in that: In the case of starting the target application, matching the process identifier corresponding to the first process to obtain the shared information corresponding to the first process includes: When the target application is started, based on a preset matching rule, shared information corresponding to the process identifier corresponding to the first process is obtained from a pre-acquired correspondence relationship, wherein the correspondence relationship includes multiple process identifiers and shared information corresponding to the multiple process identifiers.

3. The method according to claim 1, characterized in that The step of obtaining a return address of the creation function upon detecting that the first process has created any first thread by using the creation function comprises: Monitor the calling status of the creation function through the monitoring function; When the calling situation indicates that the creation function is called by the first process, determining that the first process completes creation of the first thread through the creation function; The return address of the creation function is obtained through the monitoring function.

4. The method according to claim 1, characterized in that After executing the push function to replace the context environment in the first thread with the shared information, the method further includes: When the push function is executed, calling a thread entry function corresponding to the first thread, wherein the thread entry function includes a data processing task of the first thread; The thread entry function is executed to enable the first thread to perform the data processing task.

5. The method according to claim 4, characterized in that The creation function is also used to instantiate a storage object, which includes at least one of the thread entry function and entry function parameters, and the entry function parameters are used to provide the thread entry function with parameter information required for the data processing task.

6. The method according to claim 1, characterized in that The executing the push function to replace the context environment in the first thread with the shared information corresponding to the first process includes: Obtaining the initialization status of the first thread through the push function, wherein the initialization status is used to indicate whether the initialization operation of the unified computing device architecture CUDA is completed, and the CUDA is used to run the target application; When the initialization condition indicates that the CUDA has completed the initialization operation, obtaining a data identifier of the context environment stored in the first thread; When the data identifier does not match the process identifier corresponding to the first process, the context environment in the first thread is replaced with the shared information corresponding to the first process.

7. A storage device for multi-process shared information, characterized in that: The device comprises: A first acquisition module, used to acquire a process identifier corresponding to each process in multiple processes of a target application; a matching module, configured to match a process identifier corresponding to any first process among the multiple processes, when the target application is started, to obtain shared information corresponding to the first process, wherein the shared information is used to coordinate data processing with multiple threads included in the first process, wherein the shared information corresponding to the first process includes a first field and a second field, and the first fields corresponding to different processes are the same; A second acquisition module is used to acquire a return address of the creation function when it is detected that the first process completes the creation of any first thread through the creation function; A third acquisition module is used to acquire the stack function preset in the return address; An execution module is used to execute the push function to replace the context environment in the first thread with the shared information corresponding to the first process.

8. An electronic device, characterized in that: The device comprises: a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, the method for storing multi-process shared information as described in any one of claims 1 to 6 is implemented.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the method for storing multi-process shared information according to any one of claims 1 to 6 is implemented.

10. A vehicle, characterized in that: Include at least one of the following: The storage device for multi-process shared information as claimed in claim 7; The electronic device as claimed in claim 8; The computer readable storage medium of claim 9.

Images