Lock uninstall running method and device and computer equipment

Abstract

This application discloses a lock unloading and execution method, apparatus, and computer device. The method includes: generating a host-side file and an unloading node file about the lock based on user-input instructions; the unloading node running the unloading node file to execute: sending a lock request for a target lock variable to the host; and accessing the target lock variable after the host determines that the unloading node has locked the target lock variable; the host running the host-side file to execute: upon receiving the lock request for the target lock variable from the unloading node, determining whether the unloading node can lock the target lock variable based on the current state of the target lock variable and / or the lock requests in the lock queue. This method enables the compiler to automatically generate lock-related execution files based on the instructions, ensuring consistency of the lock variable on the host and the unloading node, enabling the unloading node to successfully complete the unloading task, improving the usability of the lock in the unloading scenario, and effectively improving the work efficiency of programmers.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus and computer device for unloading a lock. Background Technology

[0002] As data volumes grow, the demands on computing power are increasing, and simply improving the computing power of a single core or a single server is no longer cost-effective. To meet the growing demand for computing power, technologies such as heterogeneous acceleration and cluster computing have been proposed and developed, aiming to improve the overall computing power of the computing system by offloading some computing tasks to other nodes.

[0003] Multithreaded programs that involve concurrent read and write operations on shared resources will experience resource contention. One way to resolve this contention is through access control using locks to protect concurrently read and written data. However, locks, as a common synchronization mechanism in programs, can become increasingly complex or even unusable as computing systems expand. If the code containing locks is offloaded to an offload node, the code running on the offload node will not function properly because the lock variables on the host and offload node are inconsistent.

[0004] Currently, mainstream compilers based on predicates, such as Open Multi-Processing (OpenMP), do not provide a mechanism for synchronizing locks between the host and unloading nodes. Therefore, programmers need to modify the unloading program code, increasing their workload and contradicting the principle of predicate-based programming—avoiding modification of the original program code. Distributed lock solutions implemented using databases, remote dictionary servers (Redis), or distributed application coordination services (ZooKeeper) can access globally maintained lock variables across all nodes in the distributed system. Therefore, the locks in the original program code can be modified to these distributed locks to adapt to the unloading scenario. However, for already developed programs, modifying the original code is labor-intensive, and this approach relies on third-party components. Summary of the Invention

[0005] This application provides a lock unloading and running method, apparatus, and computer device for implementing lock unloading and running based on a preamble, which simplifies the operation for programmers and avoids the problem of inconsistency between lock variables on the host side and the unloading node.

[0006] In a first aspect, embodiments of this application provide a lock unloading execution method, comprising: a compiler obtaining a user-input preamble, the preamble being used to instruct the generation of an executable file for the lock; the compiler generating a host-side executable file and a target unloading node executable file according to the preamble, and sending the host-side executable file to the host and the target unloading node executable file to the target unloading node; the target unloading node executable file, when run by the target unloading node, causes the target unloading node to perform: when it is necessary to lock a target lock variable, sending a first locking request for the target lock variable to the host, and accessing the target lock variable after the host determines that the target unloading node has locked the target lock variable; the host-side executable file, when run by the host, causes the host to perform: when the first locking request from the target unloading node is received, determining whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the locking requests in the lock queue.

[0007] The above scheme implements lock unloading based on a predicate. The compiler automatically generates the host-side executable file and the unloading node executable file for the lock based on the predicate, ensuring that the corresponding files are executed on both the host and unloading nodes. This guarantees the consistency of lock variables on the host and unloading nodes, allowing the unloading node to successfully complete its unloading task and improving the usability of the lock in unloading scenarios. In implementing this scheme, programmers can automatically perform the above functions through simple predicate input, effectively reducing the workload and learning cost of modifying program code and significantly improving programmer efficiency.

[0008] In one possible implementation, the preamble includes identification information for lock variables. The host-side executable and the target unloading node executable are executables targeting the lock variables, and the target lock variable belongs to the lock variables. In this implementation, the user can determine which lock variables in the unloading program will generate corresponding executables, and include the identifiers of the determined lock variables in the preamble when inputting it, so that the compiler can automatically generate the corresponding executables based on the lock variable identifiers in the preamble.

[0009] In one possible implementation, before the compiler generates the host-side executable file and the target unloading node executable file based on the preamble, the method further includes: the compiler obtaining program code from the unloading region, the program code in the unloading region being the program code unloaded to the target unloading node for execution; the compiler identifying lock variables in the program code; the host-side executable file and the target unloading node executable file being executable files targeting the lock variables, and the target lock variable being a type of the lock variable. In this implementation, the compiler can automatically identify variables in the unloading program and identify which variables are lock variables, thereby further reducing the workload of programmers in identifying lock variables and improving the efficiency of programmers.

[0010] In one possible implementation, the compiler identifies lock variables in the program code by: identifying whether lock-related functions exist in the program code; if so, identifying lock variables in the program code based on lock-related functions; and / or, the compiler runs the program code in the unloaded region through a thread, identifying lock variables in the program code based on write operations to the non-unloaded region in the program code in the unloaded region. The compiler identifies lock variables using static and / or dynamic methods. Static identification is based on common lock operation functions, which is simple and easy to operate. Dynamic identification, on the other hand, is based on write operations to the non-unloaded region during program execution, which helps to more comprehensively identify lock variables and avoid omissions.

[0011] In one possible implementation, when the host-side executable file is run on the host, the host, when determining whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the locking requests in the lock queue, specifically performs the following: determining whether the target lock variable is idle; if the target lock variable is idle, locking the target lock variable, determining the unloading node currently locking the target lock variable based on the first locking request and the locking requests in the lock queue; if the determined unloading node is not the target unloading node, adding the first locking request to the lock queue; if the determined unloading node is the target unloading node, determining that the target unloading node has successfully locked the target lock variable; if the target lock variable is already locked, adding the first locking request to the lock queue.

[0012] In one possible implementation, when the host-side executable file is run on the host, the host, when determining the unloading node currently locking the target lock variable based on the first locking request and the locking requests in the lock queue, specifically performs the following: determining the priority of the unloading node requesting access to the target lock variable based on the first locking request and the locking requests in the lock queue; and selecting the unloading node with the highest priority as the current unloading node locking the target lock variable.

[0013] In one possible implementation, when the host-side executable is run, it causes the host to also perform the following: synchronize the state of the lock variable to the target unloading node; when the target unloading node executable is run, it causes the target unloading node to send a first lock request for the target lock variable to the host, specifically performing the following: determine the state of the target lock variable based on the obtained state of the lock variable; when the target lock variable is in an idle state, send a first lock request for the target lock variable to the host; when the target lock variable is in a locked state, add the first lock request for the target lock variable to the lock waiting queue of the target unloading node, and synchronize the lock waiting queue information of the target unloading node to the host. In multi-threaded, multi-concurrency scenarios, synchronizing the lock variable state and lock waiting queue information between the host and the unloading node can further avoid resource contention.

[0014] In one possible implementation, when the target unloading node executable is run by the target unloading node, the target unloading node also performs the following: after the first thread in the target unloading node has locked and accessed the target lock variable, it determines whether there are other threads in the target unloading node's lock queue that have lock requests for the target lock variable; if not, it sends a first release request for the target lock variable to the host; if so, it determines that the thread with the highest priority among the other threads locks the target lock variable; or, it determines whether the priority of the thread with the highest priority among the other threads is lower than the priority of the host; if it is lower, it sends a release request for the target lock variable to the host; otherwise, it determines that the thread with the highest priority locks the target lock variable.

[0015] In one possible implementation, when the host-side executable file is run by the host, the host also performs the following: upon receiving a first release request for the target lock variable, it determines whether there are other unloading nodes in the lock queue that request to lock the target lock variable; if not, it releases the target lock variable, and the released target lock variable becomes idle; if it exists, it determines that the unloading node with the highest priority among the other unloading nodes locks the target lock variable; or, it determines whether the priority of the unloading node with the highest priority among the other unloading nodes is lower than the priority of the host; if it is lower, it releases the target lock variable; otherwise, it determines that the unloading node with the highest priority locks the target lock variable.

[0016] Secondly, embodiments of this application provide a lock unloading and execution method, executed by a target unloading node, comprising: the target unloading node receiving a target unloading node execution file sent by a compiler, the target unloading node execution file being generated by the compiler based on user-input instructions; the target unloading node running the target unloading node execution file and performing the following: when it is necessary to lock a target lock variable, sending a first locking request for the target lock variable to the host; and after the host determines that the target unloading node has locked the target lock variable, accessing the target lock variable.

[0017] In one possible implementation, the target unloading node runs the target unloading node executable file and further performs the following: obtaining the state of the lock variable from the host; when the target unloading node runs the target unloading node executable file and sends a first locking request for the target lock variable to the host, it specifically performs the following: determining the state of the target lock variable based on the obtained state of the lock variable; when the state of the target lock variable is idle, sending a first locking request for the target lock variable to the host; when the state of the target lock variable is locked, adding the first locking request for the target lock variable to the lock waiting queue of the target unloading node, and synchronizing the information of the lock waiting queue of the target unloading node to the host.

[0018] In one possible implementation, the target unloading node runs the target unloading node executable file and also performs the following: after the first thread in the target unloading node has locked and accessed the target lock variable, it determines whether there are other threads in the target unloading node's lock queue that have lock requests for the target lock variable; if not, it sends a first release request for the target lock variable to the host; if so, it determines that the thread with the highest priority among the other threads locks the target lock variable; or, it determines whether the priority of the thread with the highest priority among the other threads is lower than the priority of the host; if it is lower, it sends a release request for the target lock variable to the host; otherwise, it determines that the thread with the highest priority locks the target lock variable.

[0019] Thirdly, embodiments of this application provide a lock unloading method executed by a host, comprising: the host receiving a host-side executable file of the lock sent by a compiler, the host-side executable file being generated by the compiler based on user-input instructions; the host running the host-side executable file and performing the following: obtaining a first locking request from a target unloading node for a target lock variable; and determining whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the locking requests in the lock queue.

[0020] In one possible implementation, the host executes the host executable file. When determining whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the locking requests in the lock queue, the execution specifically includes: determining whether the target lock variable is idle; if the target lock variable is idle, locking the target lock variable; determining the unloading node currently locking the target lock variable based on the first locking request and the locking requests in the lock queue; if the determined unloading node is not the target unloading node, adding the first locking request to the lock queue; if the determined unloading node is the target unloading node, determining that the target unloading node has successfully locked the target lock variable; if the target lock variable is locked, adding the first locking request to the lock queue.

[0021] In one possible implementation, the host executes the host executable file, and when determining the unloading node corresponding to the current lock based on the first lock request and the lock requests in the lock queue, specifically performs the following: based on the first lock request and the lock requests in the lock queue, determines the priority of the unloading node requesting access to the target lock variable; and selects the unloading node with the highest priority as the unloading node currently locking the target lock variable.

[0022] In one possible implementation, the host executes the host executable file and also performs the following: synchronizing the state of the lock variable to the target unloading node.

[0023] In one possible implementation, the host running the host executable file further performs the following: upon receiving a first release request for the target lock variable, determining whether there are other unloading nodes in the lock queue that request to lock the target lock variable; if not, releasing the target lock variable, and the released target lock variable becomes idle; if it exists, determining that the highest priority unloading node among the other unloading nodes locks the target lock variable; or, determining whether the priority of the highest priority unloading node among the other unloading nodes is lower than the priority of the host; if lower, releasing the target lock variable; otherwise, determining that the highest priority unloading node locks the target lock variable.

[0024] Fourthly, embodiments of this application provide a lock unloading and operation device, the device including a processing module and a transceiver module, the processing module being used to execute the methods described in the first to third aspects and any implementation thereof through the transceiver module.

[0025] Fifthly, embodiments of this application provide a computer device, the computer device including a memory and a processor; the memory stores a computer program; the processor is used to call the computer program stored in the memory to perform the method as described in the first to third aspects and any implementation thereof.

[0026] Sixthly, embodiments of this application provide a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the methods described in the first to third aspects and any implementation thereof.

[0027] In a seventh aspect, embodiments of this application provide a computer program product containing instructions that, when run on a computer, cause the methods described in the first to third aspects and any implementation thereof to be executed.

[0028] For the technical effects that can be achieved by any possible implementation of any of the second to seventh aspects mentioned above, please refer to the description of the technical effects that can be achieved by the corresponding implementation scheme in the first aspect mentioned above. Repeated parts will not be discussed. Attached Figure Description

[0029] Figure 1a A computing system applicable to embodiments of this application is provided;

[0030] Figure 1bAnother computing system applicable to embodiments of this application is provided for the purposes of this application;

[0031] Figure 2a This is a schematic diagram illustrating the unloading operation principle of a lock, as provided in an embodiment of this application.

[0032] Figure 2b This is a schematic diagram of a detection and analysis module structure provided in an embodiment of this application;

[0033] Figure 2c This is a schematic diagram of the dynamic recognition process of the lead code provided in the embodiments of this application;

[0034] Figure 2d A schematic diagram illustrating improvements to existing compilers provided in this application embodiment;

[0035] Figure 2e A schematic diagram of a synchronization mechanism provided in an embodiment of this application;

[0036] Figure 2f A schematic diagram illustrating another synchronization mechanism provided in this application embodiment;

[0037] Figure 3a A flowchart illustrating a lock unloading operation method provided in an embodiment of this application;

[0038] Figure 3b This is a schematic diagram illustrating the process of the compiler generating the executable file in an embodiment of this application;

[0039] Figure 4 A flowchart illustrating another lock unloading operation method provided in this application embodiment;

[0040] Figure 5 A flowchart illustrating another lock unloading operation method provided in this application embodiment;

[0041] Figure 6 A flowchart illustrating another lock unloading operation method provided in this application embodiment;

[0042] Figure 7 A flowchart illustrating another lock unloading operation method provided in this application embodiment;

[0043] Figure 8 A flowchart illustrating another lock unloading operation method provided in this application embodiment;

[0044] Figure 9 A flowchart illustrating another lock unloading operation method provided in this application embodiment;

[0045] Figure 10 A flowchart illustrating another lock unloading operation method provided in this application embodiment;

[0046] Figure 11 This is a schematic diagram of the structure of a lock unloading and operation device provided in an embodiment of this application;

[0047] Figure 12 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0048] OpenMP is a multithreaded programming paradigm that provides a high-level abstraction of parallel algorithms. Users can add compiler directives (e.g., pragma directives in C) to the source code, allowing the compiler to automatically parallelize the program. When the directive is omitted, or if the compiler does not support OpenMP, the program degenerates into a normal program (usually serial). The code still functions correctly, but multithreading cannot be used to accelerate execution. OpenMP reduces the difficulty and complexity of parallel programming and is now widely used in parallel programming.

[0049] The current OpenMP standard supports heterogeneous acceleration using preambles. By specifying the unloading node (the node performing the unloading task) in the preamble, heterogeneous accelerated programming can be achieved. Most common compilers support OpenMP unloading compilation, which can compile the unloading program into a multi-architecture executable (fatbinary) containing both host-side code logic and unloading node code logic. This multi-architecture executable can automatically prepare the runtime environment for the unloading node during startup and complete data interaction and execution control logic during runtime, thereby quickly enabling heterogeneous accelerated programming and execution.

[0050] OpenACC is a user-driven, instruction-based, performance-portable parallel programming model that, like OpenMP, can be compiled by adding directives.

[0051] Multithreaded programs often experience concurrent access to shared resources. To avoid resource contention, one thread can lock the variable to be accessed, and after it finishes accessing it, release the lock, allowing other threads to access the released variable again, as well as perform locking and releasing operations. A variable that can be locked is called a lock variable. However, currently common compilers based on indices, such as those based on OpenMP or OpenACC, do not yet support lock unloading during compilation and execution.

[0052] In view of this, embodiments of this application provide a lock unloading and running method, which can automatically compile the unloading program code containing the lock based on the preamble, avoid the problem of inconsistency between lock variables on the host side and the unloading node, and simplify the operation of programmers.

[0053] Figure 1a An exemplary computing system applicable to embodiments of this application is provided. As shown in the figure, the computing system may include a host and at least one unloading node for executing an unloading program. The host is an independently running computer system, which may include a central processing unit (CPU), memory, and interfaces for communicating with other hardware. The host typically also has an operating system (OS) installed. The unloading node may be another processor or processing unit connected to the host, such as a CPU, graphics processing unit (GPU), neural network processing unit (NPU), or data processing unit (DPU). The unloading node may or may not have an operating system (OS) installed. Different unloading nodes may be different physical devices or different virtual nodes within the same physical device. The unloading node can be connected to the host via hardware connections, such as through a peripheral component interconnect (PCI) bus interface, or via a network. A host can be connected to one or more unloading nodes to control them. Figure 1a In the specific example shown, the compiler provided in the embodiments of this application is installed on the host. In other scenarios, the compiler can also be installed on an external device connected to the host, so that the executable file generated by the compiler can be applied to the host and the unloading node.

[0054] Figure 1a The computing system shown can be integrated into a single server; that is, a host and one or more offload nodes connected to that host can be integrated into a single server. The embodiments of this application can also be applied to computer clusters consisting of one or more servers, such as... Figure 1b As shown. Figure 1bThe computer cluster in the application includes multiple servers, such as server 1...server n, etc. The host in each server and the corresponding multiple unloading nodes can implement the unloading of the lock through the compiler provided in the embodiments of this application; or, the host in one of the multiple servers can be used as the host, and the unloading nodes connected to the host and other hosts can all be used as unloading nodes of the host.

[0055] like Figure 2a As shown, the implementation principle of this application embodiment can be basically divided into a lock variable identification process, a code compilation process, and a code execution process. The introductory text acquisition and parsing process can be achieved through... Figure 1a The compiler implementation, located on the host or in a device outside the host, can handle lock variable identification and code compilation. The code execution process can be achieved through the compiler located on the host or in other devices outside the host, as shown in the diagram. Figure 1a and Figure 1b The host and unloading nodes interact with each other. (See reference...) Figure 2a As can be seen, detection and analysis modules and code compilation modules can be integrated into the compiler, while runtime modules can be integrated into both the host and unloading nodes. The detection and analysis modules and code compilation modules generate the corresponding lock executable files based on the user-input commands and distribute them to the host and unloading nodes. The runtime modules located in the host and unloading nodes interact to ensure that the host and unloading nodes run the executable files distributed by the compiler synchronously. Furthermore, the compiler can also include a front-end module for defining the lock-related operations performed by the user.

[0056] like Figure 2b As shown, Figure 2b The detection and analysis module within the compiler can be used to analyze the uninstallation code logic to alert the user to potential lock variables in the uninstaller code. This detection phase can be divided into static and dynamic identification processes. In other words, the compiler's automatic identification of lock variables can include static and / or dynamic identification.

[0057] Static identification involves the compiler checking whether pre-defined lock-related functions, such as `spin_lock` and `std::mutex`, exist in the program code unloaded to the target unloading node (hereinafter referred to as the unloading region). If they exist, the compiler identifies the lock variables in the unloading region based on these functions. Static identification provides a simple and quick way to identify lock variables.

[0058] Dynamic identification refers to analysis performed during program code execution to obtain more accurate identification results. The compiler can run the program code in the unloaded region using a separate thread to detect read and write operations on variables in the unloaded region within the non-unloaded region, and determine whether a variable is a locked variable based on these read and write operations. For example, the dynamic identification process can be divided into an automatic modification phase of the unloaded program code and a compilation and execution phase.

[0059] like Figure 2c As shown. The automatic code modification phase can include adding constructors and destructors (the constructors are used to initialize relevant variables); identifying unloaded regions and extracting them to a separate thread for execution; adding detection enable flags before and after unloading; and identifying and instrumenting variables in the unloaded regions. The compilation and execution phase can include compiling the code in non-unloaded mode; running the code to collect read and write operations on variables; identifying potential lock variables based on read and write operations; and further, outputting an analysis report. Specifically, if a variable in the unloaded region is detected to have read and write operations in the non-unloaded region, and not all operations are reads, then that variable is considered a potential lock variable.

[0060] To obtain more accurate identification results, static and dynamic identification can be combined. First, static identification can be performed on the program code in the unloaded area, and then dynamic identification can be performed on the possible lock variables identified statically to identify the possible lock variables with higher accuracy. Alternatively, after static identification, dynamic identification can be performed on all variables in the unloaded area, and then both the possible lock variables identified statically and dynamically can be output to the user.

[0061] Taking the OpenMP-based compiler as an example, a lock-specific directive design scheme is added to the existing OpenMP standard, and lock-specific compilation adaptation functions are added to the existing compiler, such as... Figure 2d As shown, the lock unloading operation method based on the introduction in the above-mentioned technical solution of this application can be realized.

[0062] like Figure 2e As shown, in order to implement the technical solution of this application, it is possible to... Figure 1a or Figure 1bThe existing structures of the host and unloading nodes are modified with synchronization units to exchange runtime information when running the executable files provided by the compiler. The host has host runtime logic, which runs host threads and the host executable files provided by the compiler. The unloading node has unloading runtime logic, which runs the unloading node threads and the target unloading node executable files provided by the compiler. The synchronization unit on the host manages all lock variables to be synchronized and responds to requests from the unloading node. The synchronization unit in the unloading node interacts with the synchronization unit on the host to set the lock state on the unloading node based on the lock state on the host.

[0063] like Figure 2f As shown, Figure 2e The diagram shows the interaction between the various functional modules in the host and unloading nodes under the structure shown. The host operation logic and host synchronization unit are located in the host, while the unloading node synchronization unit and unloading operation logic are located in the unloading node.

[0064] In combination with the above Figures 1a to 2f The system architecture shown below, along with the internal structure of each device within the architecture, will be described in detail below as a flowchart illustrating the lock unloading and operation method provided in this application embodiment. Figure 3a As shown, the method may include the following steps:

[0065] Step 301: The compiler obtains the user-inputted introduction.

[0066] The above preamble instructs the compiler to generate the executable file for the lock. Specifically, users can input preambles to specify the lock variables involved in the unloading program and the supported lock operation functions. For example, in OpenMP, the user-input preamble could be as follows:

[0067] #pragma omp target sync_lock({lock_name}:{lock_op}[:{lock_prio}])

[0068] In this context, `omp` is the unified prefix for OpenMP specification directives, `target` is an existing `omp` unloading directive used to instruct code to run on the unloading end, `sync_lock` is the lock unloading directive provided in this embodiment, `lock_name` is the name of the lock variable involved in the unloading program, `lock_op` is the set of supported lock operation functions, which users can define through the front-end module, and `lock_prio` is the priority of the corresponding unloading node among the involved lock variables. `lock_prio` is an optional field; for example, when this field is omitted, the priority of the unloading node can be set to the same priority as the host.

[0069] It should be understood that the above-described lock introduction structure and the names of each field are examples, and the unloading introduction may include more or fewer fields than the examples above.

[0070] Step 302: The compiler generates the host-side executable file and the target unloading node executable file of the lock based on the obtained preamble.

[0071] In order to ensure that the lock maintains a consistent state with the host during unloading, both the host and the unloading node need to work together. Therefore, in this embodiment, the compiler will generate an executable file for running on the host and an executable file for running on the unloading node based on the preamble.

[0072] In some embodiments, the user-input preamble may include identifiers of lock variables; that is, the user instructs the compiler to generate executable files containing which lock variables. In other embodiments, the compiler may also automatically identify lock variables present in the program code that is unloaded to the unload node and generate corresponding executable files based on the automatically identified lock variables, further simplifying the programmer's operations and reducing their workload.

[0073] Specifically, refer to Figure 3b As shown, the compiler's code compilation function can include three parts: code parsing, code generation, and executable file generation. The process of generating the executable file based on the introductory text can include:

[0074] The code parsing section is used to obtain the user-input introductory text. Based on the lock variable name specified in the introductory text and the corresponding set of operation functions, it captures the operations of the uninstallation program code on the lock in the uninstallation node.

[0075] The code generation section generates lock management code for the host side and lock operation code for the unloading node based on the code execution logic captured in the unloading node. It also converts the lock operation code captured by the parsing section for the unloading node into built-in lock operation logic. The host-side lock management code and the unloading node-side lock operation code can be applied to the aforementioned... Figure 2e and Figure 2f The specific implementation of the synchronization unit in the host and the synchronization unit in the offloading node.

[0076] The executable file generation section compiles the host-side lock management code and the unloading node-side lock operation code generated in the previous step into host-side executable files and target unloading node executable files, respectively. These executable files can be binary files.

[0077] Step 303: The compiler sends the host-side executable file to the host and the target unload node executable file to the target unload node.

[0078] For example, when the compiler is installed on the host, the compiler sends the executable file from the host to the host, which is a file transfer between different program components within the device; while the compiler sends the executable file of the target unloading node to the target unloading node, which can be achieved by the compiler sending the executable file of the target unloading node through the host.

[0079] Step 304a: The target unloading node runs the target unloading node executable file and performs the following steps: when it is necessary to lock the target lock variable, it sends a first lock request for the target lock variable to the host; after the host determines that the target unloading node has locked the target lock variable, it accesses the target lock variable.

[0080] Access in the embodiments of this application includes, but is not limited to, read operations and / or write operations.

[0081] Step 304b: The host executes the host executable file and performs the following steps: When the first locking request of the target unloading node for the target lock variable is obtained, the host determines whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the locking requests in the lock queue.

[0082] The states of a lock variable include a locked state and an idle state. A locked state indicates that the lock variable is currently locked by a node (which can be an offloading node or a host), and other nodes are not allowed to access the lock variable. An idle state indicates that the lock variable is not locked and can be accessed by any node, or it may be locked.

[0083] The lock waiting queue is a queue of lock requests waiting for execution. For example, if unloading node 1 and unloading node 2 simultaneously request to lock lock variable A, since unloading node 1 has a higher priority than unloading node 2, the host will respond to unloading node 1's request first, and unloading node 2's lock request will be added to the lock waiting queue to wait. As another example, if unloading node 1 and unloading node 2 have the same priority, but unloading node 1 sends its lock request for lock variable A first, and unloading node 2 also needs to lock lock variable A before unloading node 1's access operation on lock variable A is completed, then unloading node 2's lock request will be added to the lock waiting queue to wait.

[0084] The host can determine whether the target unloading node can lock the target lock variable based solely on its current state. For example, if the target lock variable is currently locked, the target unloading node cannot lock it; if it is currently idle, it can lock it. Alternatively, the host can determine whether the target unloading node can lock the target lock variable based on its state and the lock queue. The specific implementation will be detailed later.

[0085] In the above embodiments of this application, lock unloading execution based on a preface is implemented. The compiler automatically generates the host-side executable file and the unloading node executable file for the lock based on the preface, ensuring that the host and unloading nodes execute the corresponding files. This guarantees the consistency of lock variables on the host and the unloading node, enabling the unloading node to successfully complete the unloading task and improving the usability of the lock in unloading scenarios. In implementing this scheme, programmers can automatically implement the above functions through simple preface input, effectively reducing the workload and learning cost of modifying program code and significantly improving programmer efficiency.

[0086] As mentioned earlier, when the host-side executable file generated by the compiler is executed on the host, it enables the host to determine whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and the locking requests in the lock queue. In some embodiments, when the host runs the host-side executable file to implement the above functions, it can execute, for example... Figure 4 The steps shown are as follows:

[0087] Step 401: The host receives a lock request 1 sent by unloading node 1. Here, unloading node 1 is the target unloading node mentioned above.

[0088] Step 402: The host determines whether the target lock variable is currently in an idle state. If the target lock variable is in an idle state, proceed to step 403; if the target lock variable is in a locked state, proceed to step 405.

[0089] Step 403: Lock the target lock variable. If the locking is successful, proceed to step 404; otherwise, proceed to step 405.

[0090] Step 404: The host determines the unloading node for this lock on the target lock variable based on lock request 1 and the lock requests in the lock queue. Specifically, the unloading node determined by the host for successful locking can be unloading node 1 that sent lock request 1, or it can be another unloading node corresponding to a lock request in the lock queue. If the unloading node determined for this lock on the target lock variable is another unloading node, it means that unloading node 1 cannot currently lock the target lock variable.

[0091] Step 405: The host adds lock request 1 to the lock queue.

[0092] After step 405 above, the host can continue to query the status of the target lock variable to process the locking requests in the peer lock queue. In one specific implementation, the host can periodically or sequentially query the status of the target lock variable. If the target lock variable is in an idle state and there is a locking request for that target lock variable in the peer lock queue, then the target lock variable is locked, and the currently successfully locked unloading node is determined.

[0093] Optionally, when performing step 404 above, the host can determine the priority of each unloading node. For example, the host can determine the priority based on, for example, the priority of each unloading node. Figure 5 The steps shown determine the unloading node.

[0094] like Figure 5 As shown, the process of determining the unloaded node on the host side may include:

[0095] Step 501: Determine the priority of the unloading node corresponding to each locking request for the target lock variable in the lock queue.

[0096] Step 502: Determine the unloading node with the highest priority as the unloading node for locking the target lock variable this time.

[0097] Optionally, if there are multiple unloading nodes with the highest priority, the unloading node with the highest priority and the earliest lock request time can be used as the unloading node for locking the target lock variable this time. In some other embodiments, the priority of each unloading node may not be set, and the unloading node that successfully locked this time can be determined in step 502 according to the request time of sending the lock request.

[0098] Step 503: Update the lock queue. For example, if in step 502 it is determined that the unloading node 2 that sent lock request 2 is the unloading node currently locking the target lock variable, in step 503, the host deletes lock request 2 from the lock queue.

[0099] In multi-threaded and multi-concurrency scenarios, in order to further avoid resource contention, the host and unloading nodes can also synchronize information, such as the synchronization of lock variable states and lock queue information, thereby reducing the situation where lock requests sent by the unloading node cannot be responded to in a timely manner.

[0100] In one possible design, when the host runs the host executable, it can also synchronize the state of each lock variable to the target unloading node. Furthermore, the host can synchronize the state of each lock variable to all unloading nodes (regardless of whether an unloading node has a locking requirement). Correspondingly, when a target unloading node needs to lock a target lock variable, it can first determine the state of the target lock variable based on the acquired lock variable state. If the target lock variable is currently idle, the target unloading node directly sends a first locking request to the host. If the target lock variable is currently locked, the target unloading node can determine that the host cannot currently respond to its locking request, and then adds the first locking request to the lock queue.

[0101] Optionally, the lock queue can be maintained uniformly by the host, or it can be maintained separately by the host and each unloading node. For example, when the host simultaneously receives lock requests from unloading node 1 and unloading node 2 for the same target lock variable, it determines that unloading node 1 will lock first, and adds the lock request of unloading node 2 to the lock queue in the host. When unloading node 3 needs to lock the target lock variable but the target lock variable is currently locked, unloading node 3 adds the lock request to the lock queue in its own queue. Unloading node 3 can periodically or triggerically synchronize the lock queue information in its queue to the host, enabling the host to obtain the lock request from unloading node 3. After the lock queue information is synchronized, the lock queue in the host can contain the lock requests from each unloading node, thus responding to the lock requests of each unloading node one by one.

[0102] It should be understood that the operation of the unloading node synchronizing the lock queue information to the host can be either active or passive. For example, unloading node 3 can periodically or triggeredly actively send the lock queue information in unloading node 3 to the host; alternatively, the host can periodically or triggeredly query the lock queue information of each unloading node, and each unloading node passively sends its own lock queue information to the host. Similarly, the host can synchronize the state of the lock variable to the target unloading node by periodically or triggeredly actively sending the state of the lock variable to the target lock variable; or the unloading node can periodically or triggeredly query the state of the lock variable from the host, thereby causing the host to synchronize the state of the lock variable to the unloading node.

[0103] In one specific embodiment, the host can synchronize lock variables and lock queues through the host-side synchronization unit, and the target unloading node can also synchronize lock variables and lock queues through the unloading node synchronization unit. For example... Figure 2eAs shown, the host-side synchronization unit determines the state of each lock variable based on the host's locking and releasing operations on the lock variables, and then periodically sends the state of each lock variable to the unloading node synchronization unit of the unloading node. The host-side synchronization unit can also periodically obtain the lock queue information of each unloading node from the unloading node synchronization unit. When an unloading node has a locking requirement, it first obtains the state of the target lock variable from the unloading node synchronization unit to determine whether to send a locking request to the host or add the request to the unloading node synchronization unit.

[0104] After a target unloading node locks and accesses a target lock variable, it can send a release request to the host, requesting the unlocking of the target lock variable so that other nodes can access or lock it. If the target unloading node sends a release request to the host, Figure 6 An exemplary procedure for releasing a lock on the host side is provided, which may specifically include:

[0105] Step 601: The host receives a release request for lock variable A sent by unloading node 1. Unloading node 1 is the node currently locking lock variable A.

[0106] Step 602: The host determines whether there are still lock requests for lock variable A in the lock queue. If so, proceed to step 603; otherwise, proceed to step 604.

[0107] Step 603: The host determines the unloading node that sent the locking request for lock variable A and locks lock variable A.

[0108] If there are still lock requests for lock variable A, directly determining that the unloading node of the lock is locked for lock variable A can avoid the cumbersome steps of releasing and relocking, simplify the process, save time and improve system efficiency.

[0109] If there are multiple lock requests for lock variable A in the lock queue, the host can determine the unloading node based on the priority and / or the time of the lock request.

[0110] Step 604: Release lock variable A. After release, lock variable A becomes idle, allowing other nodes to access and lock it.

[0111] Figure 7 An alternative host-side lock release process is provided as an example, such as Figure 7 As shown, the host can perform the following steps:

[0112] Step 701: The host receives the release request for lock variable A sent by unload node 1.

[0113] Step 702: The host determines whether there are still lock requests for lock variable A in the lock queue. If so, proceed to step 703; otherwise, proceed to step 705.

[0114] Step 703: The host determines whether the priority of the highest-priority unloading node requesting to lock lock variable A is lower than the priority of the host. If it is lower, proceed to step 705; otherwise, proceed to step 704.

[0115] Step 704: The host determines that the highest priority unloading node locks lock variable A.

[0116] Step 705: Release the lock variable A.

[0117] In one possible implementation, the target unloading node can include multiple unloading threads, each of which can request to lock and release the target lock variable. In this case, the lock queue of the target unloading node may contain lock requests from different threads. The host can distinguish between lock requests from different threads of the same target unloading node, or it can choose not to distinguish them and, after determining that the target unloading node has successfully locked the target lock variable, let the target unloading node determine the locking thread itself, thus simplifying the host's process.

[0118] exist Figure 8 In the specific embodiment shown, the target unloading node determines the thread to be locked, which may specifically include:

[0119] Step 801: The target unloading node successfully locked lock variable A.

[0120] Step 802: The target unloading node determines the highest-priority unloading thread among the lock requests for lock variable A based on its lock queue. When no thread priority is set, the thread can also be determined based on the time the lock request was added to the lock queue. Alternatively, the unloading thread can be determined based on thread priority and / or the time it was added to the lock queue.

[0121] Step 803: The target unloading node wakes up the unloading thread identified above. That is, it notifies the unloading thread that it has successfully locked the target lock variable and can access it.

[0122] Step 804: The target unloading node updates its lock queue.

[0123] After the unloading thread that successfully acquired the lock in the target unloading node finishes accessing the target lock variable... Figure 9 An exemplary release process for a target unloading node is provided. Figure 9 It is assumed that the current lock on the target lock variable is held by unloading thread 1.

[0124] Figure 9 The process of releasing the lock on the target unloading node may include the following steps:

[0125] Step 901: The unloading thread 1 of the target unloading node requests to release the lock on the target lock variable.

[0126] Step 902: The target unloading node checks whether there is a lock request for the target lock variable in its lock queue. If there is, proceed to step 903; otherwise, proceed to step 906.

[0127] Step 903: The target unload node obtains the priority of the thread requesting the lock.

[0128] Step 904: The target unloading node determines whether the highest priority of the thread requesting the lock is lower than the priority of the host. If it is lower, proceed to step 906; otherwise, proceed to step 905.

[0129] Step 905: The target unloading node determines the highest priority thread to lock the target lock variable.

[0130] Step 906: The target unloading node sends a release request for the target lock variable to the host.

[0131] Optionally, the target unloading node may not perform step 904 above. That is, when the target unloading node determines that there are other unloading threads requesting to lock the target lock variable, it directly determines that the unloading thread with the highest priority locks the target lock variable; or, when no unloading thread priority is set, it determines that the unloading thread that requested to lock earliest locks the target lock variable based on the time of the lock request.

[0132] To more clearly understand the embodiments of requesting lock and requesting release described above in this application, the following is in conjunction with... Figure 10 The specific embodiments shown will be described in detail.

[0133] exist Figure 10 In the illustrated embodiment, it is assumed that the host, unloading node 1, and unloading node 2 have the same priority. The host, unloading node 1, and unloading node 2 execute the following steps by running their respective lock-related executable files:

[0134] Step 1001: Host-side runtime environment preparation. This includes preparing the runtime environment for the host and each unloading node.

[0135] Step 1002: Start the host thread on the host side and control the unloading node 1 to start the corresponding unloading thread.

[0136] After the host thread starts, the host periodically sends the status of each lock variable to each unloading node, and periodically queries the lock queue of each unloading node.

[0137] Step 1003: The host thread requests to lock lock variable 1. Since lock variable 1 is currently in an idle state, and there are no other nodes in the lock queue maintained by the host, the host successfully locks lock variable 1.

[0138] Step 1004: Thread 1 in unloading node A requests to lock lock variable 1. Since unloading node A determines that the current state of lock variable 1 is locked based on the periodically obtained lock variable state, the lock request of thread 1 in unloading node A is added to the lock waiting queue of unloading node A.

[0139] Step 1005: The host completes the access to lock variable 1 and releases it.

[0140] Step 1006: The host obtains the lock request of thread 1 of unloading node A for lock variable 1 based on the lock queue information of the unloading node obtained periodically, and locks lock variable 1.

[0141] Step 1007: After unloading node A and confirming that node A has successfully locked lock variable 1, wake up thread 1 and confirm that thread 1 has successfully locked lock variable 1.

[0142] Step 1008: Thread 2 of unloading node A requests to lock lock variable 1. Since lock variable 1 is currently locked, the request of thread 2 of unloading node A is added to the lock queue of unloading node A.

[0143] Step 1009: Thread 1 of unloading node B requests to lock lock variable 1. Based on the periodically obtained lock variable status, unloading node B determines that lock variable 1 is currently locked, so the request of thread 1 of unloading node B is added to the lock waiting queue of unloading node B.

[0144] Step 1010: After thread 1 of unloading node A completes its access to lock variable 1, thread 2 of unloading node A locks the lock variable. After thread 1 of unloading node A finishes its access, unloading node A determines, based on its lock queue, that thread 2 requests to lock lock variable 1, and that thread 2's priority is not lower than that of the host. Thread 2 is then awakened, and it is determined that thread 2 will lock lock variable 1.

[0145] Step 1011: Unload node A thread 2 to complete access to lock variable 1 and send a request to release lock variable 1 to the host.

[0146] Step 1010: Based on the periodically obtained lock queue synchronization information of each unloading node, the host determines that unloading node B requests to lock lock variable 1, and the priority of unloading node B is not lower than the priority of the host. Therefore, unloading node B successfully locks lock variable 1.

[0147] Step 1013: Unload node B and determine that thread 1 has locked lock variable 1. Wake up thread 1 and determine that thread 1 will lock lock variable 1.

[0148] Step 1014: Thread 1 of node B completes its access to lock variable 1 and requests the release of lock variable 1.

[0149] Step 1015: Based on the periodically obtained lock queue synchronization information of each unloading node, the host determines that there is currently no lock request for lock variable 1, and releases lock variable 1.

[0150] Optionally, the locking request sent by the unloading node to the host may include a first type of locking request or a second type of locking request. A first type of locking request means that after receiving a locking request, the host, regardless of whether the locking is successful or not, reports the status to the unloading node. If the report indicates that locking is currently impossible, the first type of locking request is added to the waiting queue. The locking requests in the aforementioned embodiments are all exemplified by the first type of locking request, which helps prevent contention issues caused by concurrent locking and reduces waiting time. A second type of locking request means that after receiving a locking request, the host only reports the status to the unloading node after successful locking. If locking is currently impossible, the locking request remains in a waiting state.

[0151] Specifically, the types of locking requests supported by the host and target unloading nodes can be defined through the set of lock operation functions. For example, in the aforementioned embodiment, lock_op in the introduction represents the set of lock operation functions; by defining lock_op, the types of locking and releasing requests supported by the host and target unloading nodes can be determined.

[0152] Based on the same technical concept, this application also provides a lock unloading and operation device for implementing the above method embodiments. Figure 11 The schematic diagram of the lock unloading and operation device provided in this application embodiment is shown in the figure. The device includes a processing module 1101 and a transceiver module 1102. The processing module 1101 is used to process information. The transceiver module 1102 is used to receive information sent by other devices or to send information to other devices.

[0153] For example, the device may be a compiler in the above method embodiments, a target unloading node in the above method embodiments, or a host in the above method embodiments.

[0154] When the device is a compiler, the processing module 1101 is used to obtain the user input of the preamble, which is used to instruct the generation of the lock execution file, and to generate the host-side execution file and the target unloading node execution file according to the preamble; the transceiver module 1102 is used to send the host-side execution file to the host and send the target unloading node execution file to the target unloading node.

[0155] Furthermore, the processing module 1101 may further include, for example, Figure 2a The diagram shows the front-end module, detection and analysis module, and code compilation module. The front-end module is used for defining lock-related operations by the user; the detection and analysis module can automatically identify lock variables in the unloading region program code and output a lock variable analysis report; the code compilation module is used to generate the host-side executable file and the target unloading node executable file based on the user-input instructions.

[0156] Furthermore, the modules described above can also be used to support other processes executed by the compiler in the above method embodiments. The beneficial effects are described above and will not be repeated here.

[0157] When the device is a target unloading node, the transceiver module 1102 is used to receive the target unloading node executable file sent by the compiler, which is generated by the compiler based on the user-input instructions; the processing module 1101 is used to run the target unloading node executable file, so that the unloading node performs the following: when it is necessary to lock the target lock variable, it sends a first lock request for the target lock variable to the host, and after the host determines that the unloading node has locked the target lock variable, it accesses the target lock variable.

[0158] Furthermore, the aforementioned modules can also be used to support other processes executed by the target unloading node in the above method embodiments. The beneficial effects are described above and will not be repeated here.

[0159] When the device is a host, the transceiver module 1102 is used to receive the host executable file of the lock sent by the compiler. The host executable file is generated by the compiler based on the introductory input by the user. The processing module 1101 is used to run the host executable file, so that the host performs the following: obtaining the first locking request of the target unloading node; and determining whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the locking requests in the lock queue.

[0160] Furthermore, the aforementioned modules can also be used to support other processes executed on the host side in the above method embodiments. The beneficial effects are described above and will not be repeated here.

[0161] Based on the same technical concept, embodiments of this application also provide a computer device. This computer device includes, for example: Figure 12 The processor 1201 shown, and the communication interface 1202 connected to the processor 1201.

[0162] The processor 1201 can be a general-purpose processor, a microprocessor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or one or more integrated circuits used to control the execution of the program in this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules in the processor.

[0163] The communication interface 1202 is used to communicate with other devices, such as PCI bus interface, Ethernet, radio access network (RAN), wireless local area network (WLAN), etc.

[0164] In this embodiment of the application, the processor 1201 is used to call the communication interface 1202 to perform the functions of receiving and / or sending, and to perform the method as described in any of the previous possible implementations.

[0165] Furthermore, the computer device may also include a memory 1203 and a communication bus 1204.

[0166] Memory 1203 is used to store program instructions and / or data so that processor 1201 can call the instructions and / or data stored in memory 1203 to implement the aforementioned functions of processor 1201. Memory 1203 can be read-only memory (ROM) or other types of static storage devices that can store static information and instructions, random access memory (RAM) or other types of dynamic storage devices that can store information and instructions, electrically erasable programmable read-only memory (EEPROM), or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer, but is not limited thereto. Memory 1203 can exist independently, such as off-chip memory, and is connected to processor 1201 via communication bus 1204. Memory 1203 can also be integrated with processor 1201.

[0167] The communication bus 1204 may include a path for transmitting information between the aforementioned components.

[0168] For example, the computer device may be the compiler in the above method embodiments, the target unloading node in the above method embodiments, or the host in the above method embodiments.

[0169] When the computer device is a compiler, the processor 1201 is used to obtain a preamble input by the user, the preamble being used to instruct the generation of an executable file for the lock; generate a host-side executable file and a target unloading node executable file according to the preamble, and send the host-side executable file to the host and the target unloading node executable file to the target unloading node.

[0170] Furthermore, the aforementioned components can also be used to support other processes executed by the compiler in the above method embodiments. The beneficial effects are described above and will not be repeated here.

[0171] When the computer device is the target unloading node, the processor 1201 is used to receive the target unloading node executable file through the communication interface 1202. The target unloading node executable file is generated by the compiler based on the user input. The processor 1201 runs the target unloading node executable file and performs the following: when it is necessary to lock the target lock variable, it sends a first lock request for the target lock variable to the host. After the host determines that the computer device has locked the target lock variable, it accesses the target lock variable.

[0172] Furthermore, the aforementioned components can also be used to support other processes executed by the target unloading node in the above method embodiments. The beneficial effects are described above and will not be repeated here.

[0173] When the computer device is a host device, the processor 1201 is used to receive the host-side executable file of the lock through the communication interface 1202. The host-side executable file is generated by the compiler based on the user-input instructions. The host-side executable file is run, causing the computer device to perform the following: obtain the first locking request of the target unloading node; determine whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the locking requests in the lock queue.

[0174] Furthermore, the aforementioned components can also be used to support other processes executed on the host side in the above method embodiments. The beneficial effects are described above and will not be repeated here.

[0175] Based on the same technical concept, embodiments of this application also provide a computer-readable storage medium storing computer-readable instructions, which, when executed on a computer, cause the steps performed by the compiler, unload node, or host in the above method embodiments to be executed.

[0176] Based on the same technical concept, this application also provides a computer program product containing instructions that, when run on a computer, cause the steps executed by the compiler in the above method embodiments to be performed.

[0177] It should be understood that in the description of this application, terms such as "first" and "second" are used only for distinguishing purposes and should not be construed as indicating or implying relative importance or order. References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, phrases such as "in one embodiment," "in some embodiments," "in other embodiments," and "in still other embodiments" appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0178] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0179] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more flowchart illustrations and / or one or more block diagrams.

[0180] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams.

[0181] These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0182] Although preferred embodiments of this application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of this application.

[0183] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of the embodiments of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

Claims

1. A method for unloading and running a lock, characterized in that, include: The compiler obtains a preamble from the user, which instructs the executable file that generates the lock; The compiler generates a host-side executable file and a target unloading node executable file based on the preamble, and sends the host-side executable file to the host and the target unloading node executable file to the target unloading node. When the target unloading node executable file is run by the target unloading node, the target unloading node performs the following: when it is necessary to lock the target lock variable, it sends a first lock request for the target lock variable to the host, and after the host determines that the target unloading node has locked the target lock variable, it accesses the target lock variable. When the host-side executable file is run by the host, the host performs the following: upon receiving the first locking request from the target unloading node, it determines whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the locking requests in the lock queue. Before the compiler generates the host-side executable and the target unloading node executable based on the preamble, the method further includes: The compiler obtains the program code of the uninstallation region, which is the program code to be executed when uninstalled to the target uninstallation node; The compiler identifies lock variables in the program code; the host-side executable file and the target unloading node executable file are executable files targeting the lock variables, and the target lock variable belongs to the lock variables.

2. The method according to claim 1, characterized in that, The introduction includes identification information for the lock variable. The host-side executable file and the target unloading node executable file are executable files for the lock variable, and the target lock variable belongs to the lock variable.

3. The method according to claim 1, characterized in that, The compiler identifies lock variables in the program code, including: The compiler identifies whether there are lock-related functions in the program code; if so, it identifies lock variables in the program code based on the lock-related functions; and / or The compiler runs the program code of the unloaded region through a thread, and identifies the lock variables in the program code based on the write operations of the program code of the unloaded region to the non-unloaded region.

4. The method according to any one of claims 1-3, characterized in that, When the host-side executable file is run on the host, the host, when determining whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the lock requests in the lock queue, specifically executes: Determine whether the target lock variable is in an idle state; If the target lock variable is in an idle state, lock the target lock variable and determine the unloading node that is currently locking the target lock variable based on the first locking request and the locking requests in the lock queue; if the determined unloading node is not the target unloading node, add the first locking request to the lock queue; if the determined unloading node is the target unloading node, determine that the target unloading node has successfully locked the target lock variable. If the target lock variable is in a locked state, the first locking request is added to the lock queue.

5. The method according to claim 4, characterized in that, When the host-side executable file is run on the host, the host, when determining the unloading node for the target lock variable based on the first locking request and the locking requests in the lock queue, specifically executes: Based on the first locking request and the locking requests in the lock queue, determine the priority of the unloading node that requests access to the target lock variable; The node with the highest priority is selected as the current node to lock the target lock variable.

6. The method according to any one of claims 1-3, characterized in that, When the executable file is run on the host, the host also performs the following: synchronizing the state of the lock variable to the target unloading node; When the target unloading node executable file is run by the target unloading node, causing the target unloading node to send a first locking request for the target lock variable to the host, the following specific actions are performed: Based on the obtained state of the lock variable, determine the state of the target lock variable; When the target lock variable is in an idle state, a first locking request for the target lock variable is sent to the host. When the target lock variable is in a locked state, the first lock request for the target lock variable is added to the lock queue of the target unloading node, and the information of the lock queue of the target unloading node is synchronized to the host.

7. The method according to any one of claims 1-3, characterized in that, When the target uninstall node executable file is run by the target uninstall node, the target uninstall node also executes: After the first thread in the target unloading node has locked and accessed the target lock variable, it is determined whether there are other threads of the target unloading node in the lock queue of the target unloading node that have lock requests for the target lock variable. If it does not exist, send a first release request for the target lock variable to the host. If it exists, determine that the thread with the highest priority among the other threads locks the target lock variable; or, determine whether the priority of the thread with the highest priority among the other threads is lower than the priority of the host. If it is lower, send a release request for the target lock variable to the host. Otherwise, determine that the thread with the highest priority locks the target lock variable.

8. The method according to any one of claims 1-3, characterized in that, When the executable file on the host is run, the host also executes: When a first release request for the target lock variable is received, it is determined whether there are other unloading nodes in the lock queue that have lock requests for the target lock variable; If it does not exist, the target lock variable is released, and the state of the target lock variable after release becomes idle. If it exists, determine that the highest priority uninstallation node among the other uninstallation nodes locks the target lock variable; or, determine whether the priority of the highest priority uninstallation node among the other uninstallation nodes is less than the priority of the host. If it is less, release the target lock variable; otherwise, determine that the highest priority uninstallation node locks the target lock variable.

9. A method for unloading and running a lock, characterized in that, include: The target unload node receives the target unload node executable file sent by the compiler, which is generated by the compiler based on the introductory text input by the user; The target unloading node runs the target unloading node executable file and executes: When it is necessary to lock the target lock variable, a first lock request for the target lock variable is sent to the host. After the host determines that the target unloading node has locked the target lock variable, the target lock variable is accessed. The target unloading node runs the target unloading node executable file and also performs the following: obtains the state of the lock variable from the host. The target unloading node runs the target unloading node executable file, and when executing the first locking request to send the target lock variable to the host, it specifically performs the following: The state of the target lock variable is determined based on the obtained state of the lock variable; When the target lock variable is in an idle state, a first locking request for the target lock variable is sent to the host. When the target lock variable is in a locked state, the first lock request for the target lock variable is added to the lock queue of the target unloading node, and the information of the lock queue of the target unloading node is synchronized to the host.

10. The method according to claim 9, characterized in that, The target unloading node runs the target unloading node executable file and also executes: After the first thread in the target unloading node has locked and accessed the target lock variable, it is determined whether there are other threads of the target unloading node in the lock queue of the target unloading node that have lock requests for the target lock variable. If it does not exist, send a first release request for the target lock variable to the host. If it exists, determine that the thread with the highest priority among the other threads locks the target lock variable; or, determine whether the priority of the thread with the highest priority among the other threads is lower than the priority of the host. If it is lower, send a release request for the target lock variable to the host. Otherwise, determine that the thread with the highest priority locks the target lock variable.

11. A method for unloading and running a lock, characterized in that, include: The host receives the host executable file sent by the compiler, which is generated by the compiler based on the intro input by the user; The host executes the host executable file, and performs the following: Obtain the first locking request from the target unloading node for the target lock variable; determine whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the locking requests in the lock queue. The host executes the host executable file, and when determining whether the target unloading node can lock the target lock variable based on the current state of the target lock variable and / or the lock requests in the lock queue, it specifically executes the following: Determine whether the target lock variable is in an idle state; If the target lock variable is in an idle state, lock the target lock variable and determine the unloading node that is currently locking the target lock variable based on the first locking request and the locking requests in the lock queue; if the determined unloading node is not the target unloading node, add the first locking request to the lock queue; if the determined unloading node is the target unloading node, determine that the target unloading node has successfully locked the target lock variable. If the target lock variable is in a locked state, the first locking request is added to the lock queue.

12. The method according to claim 11, characterized in that, The host executes the host executable file, and when determining the unloading node corresponding to the current lock based on the first lock request and the lock requests in the lock queue, it specifically executes: Based on the first locking request and the locking requests in the lock queue, determine the priority of the unloading node that requests access to the target lock variable; The node with the highest priority is selected as the current node to lock the target lock variable.

13. The method according to claim 11 or 12, characterized in that, The host machine runs the host machine executable file and also executes: The state of the lock variable is synchronized to the target unloading node.

14. The method according to claim 11 or 12, characterized in that, The host machine runs the host machine executable file and also executes: When a first release request for the target lock variable is received, it is determined whether there are other unloading nodes in the lock queue that have lock requests for the target lock variable; If it does not exist, the target lock variable is released, and the state of the target lock variable after release becomes idle. If it exists, determine that the highest priority uninstallation node among the other uninstallation nodes locks the target lock variable; or, determine whether the priority of the highest priority uninstallation node among the other uninstallation nodes is less than the priority of the host. If it is less, release the target lock variable; otherwise, determine that the highest priority uninstallation node locks the target lock variable.

15. A lock unloading and operation device, characterized in that, include: A processing module and a transceiver module, wherein the processing module is configured to perform the method as described in any one of claims 1-14 via the transceiver module.

16. A computer device, characterized in that, The computer device includes a memory and a processor; The memory stores computer programs; The processor is used to invoke a computer program stored in the memory to perform the method according to any one of claims 1-14.

17. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the method as described in any one of claims 1-14.

Images