Method, device and equipment for dynamically switching program execution path during operation and medium

Abstract

The invention relates to the technical field of computer software, and discloses a method, a device, equipment and a medium for dynamically switching program execution paths during runtime, and the method comprises the following steps: loading a plurality of execution paths of the same function task when a program is started, and collecting hardware capability information to determine a current execution path; and continuously collecting real-time hardware capability information during the program running period, re-matching and determining a target execution path, and when the target execution path is inconsistent with the current execution path, updating the current execution path identifier through a thread synchronization mechanism, so that the program always adopts the execution path with the highest matching degree. According to the invention, by sensing the hardware capability change and dynamically updating the execution path during operation, adaptive switching of the execution path is realized without restarting, so that the performance waste is reduced, the service interruption is avoided, and the resource utilization efficiency and the system operation stability are improved.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a method, apparatus, device, and medium for dynamically switching program execution paths at runtime. Background Technology

[0002] As processor architectures continue to evolve, general-purpose computing platforms typically support multiple instruction set extensions simultaneously, with variations in instruction set support and performance characteristics across different hardware environments. To improve operational efficiency, existing software systems generally pre-provide multiple execution paths adapted to different hardware capabilities for the same functional task, and select one of these execution paths as the entry point during program startup through hardware capability detection. This approach balances compatibility and performance in a static runtime environment and is therefore widely adopted.

[0003] However, in existing technologies, execution path selection is typically only bound once during program startup and remains unchanged during program execution. In actual operation, the hardware environment in which the program operates may change; for example, available computing resources may be adjusted, or the running entity may be migrated to an environment with different hardware capabilities. Because the execution path is fixed at startup, the program cannot reassess and select a more suitable execution path based on changes in the current hardware capabilities during runtime. This may result in the program running on an execution path that is incompatible with the actual hardware capabilities for an extended period, leading to underutilization of hardware resources.

[0004] Furthermore, existing technologies typically lack a systematic control mechanism for runtime path updates when the execution path binding object is accessed concurrently by multiple threads. When adjustments to the execution path are needed during program execution, failure to effectively synchronize and coordinate the reading and updating of path identifiers can easily lead to concurrent access conflicts, affecting the consistency and stability of program execution. Therefore, existing technologies still have significant shortcomings in simultaneously satisfying execution path adaptability and concurrency safety in dynamic runtime environments. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for dynamically switching program execution paths at runtime, aiming to solve the technical problem that existing technologies only bind execution paths when the program starts, and cannot detect changes in hardware capabilities during operation and safely switch to a more suitable execution path.

[0006] To achieve the above objectives, the present invention provides a method for dynamically switching program execution paths at runtime, comprising: When the program starts, multiple different versions of execution paths for the same functional task are loaded to form an execution path set, and execution path description information containing hardware capability requirements is generated for each execution path in the execution path set. When the program starts, it collects the initial hardware capability information of the current operating environment; Based on the initial hardware capability information and the execution path description information, the initial execution path with the highest matching degree with the initial hardware capability information is determined from the execution path set, and the identifier of the initial execution path is configured as the current execution path identifier; During program execution, it responds to monitoring trigger conditions and collects real-time hardware capability information of the current operating environment; Based on the real-time hardware capability information and the execution path description information, the target execution path with the highest matching degree with the real-time hardware capability information is determined from the execution path set; The identifier of the target execution path is compared with the identifier of the current execution path. If the identifier of the target execution path is inconsistent with the identifier of the current execution path, the identifier of the current execution path is updated to the identifier of the target execution path using a thread synchronization mechanism.

[0007] Furthermore, to achieve the above objectives, the present invention provides an apparatus for dynamically switching program execution paths at runtime, comprising: The execution path registration module is used to load multiple different versions of execution paths for the same functional task to form an execution path set when the program starts, and to generate execution path description information containing hardware capability requirements for each execution path in the execution path set. The hardware capability acquisition module is used to acquire initial hardware capability information of the current operating environment when the program starts. The initial path decision module is used to determine the initial execution path with the highest matching degree with the initial hardware capability information from the execution path set based on the initial hardware capability information and the execution path description information, and configure the identifier of the initial execution path as the current execution path identifier; The runtime hardware monitoring module is used to collect real-time hardware capability information of the current operating environment in response to monitoring trigger conditions during program execution. The dynamic path evaluation module is used to determine the target execution path with the highest matching degree with the real-time hardware capability information from the execution path set based on the real-time hardware capability information and the execution path description information; The execution path switching control module is used to compare the identifier of the target execution path with the identifier of the current execution path, and when the identifier of the target execution path is inconsistent with the identifier of the current execution path, it uses a thread synchronization mechanism to update the identifier of the current execution path to the identifier of the target execution path.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a program that dynamically switches program execution paths at runtime, stored in the memory and executable on the processor, wherein when the program that dynamically switches program execution paths at runtime is executed by the processor, it implements the steps of the method for dynamically switching program execution paths at runtime as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a program for dynamically switching program execution paths at runtime, wherein when the program for dynamically switching program execution paths at runtime is executed by a processor, it implements the steps of the method for dynamically switching program execution paths at runtime as described above.

[0010] Beneficial Effects: This invention relates to the field of computer software technology and discloses a method, apparatus, device, and medium for dynamically switching program execution paths at runtime. The method includes: loading multiple execution paths for the same functional task at program startup and collecting hardware capability information to determine the current execution path; continuously collecting real-time hardware capability information during program execution, re-matching and determining the target execution path, and updating the current execution path identifier through a thread synchronization mechanism when the target execution path is inconsistent with the current execution path, ensuring the program always uses the execution path with the highest matching degree. This invention achieves adaptive switching of execution paths without restarting by sensing changes in hardware capabilities during runtime and dynamically updating the execution path, thereby reducing performance waste, avoiding service interruptions, and improving resource utilization efficiency and system stability. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a method of dynamically switching program execution paths during runtime, according to an embodiment of the present invention. Figure 2 This is a flowchart illustrating an embodiment of the method for dynamically switching program execution paths during runtime according to the present invention. Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the device for dynamically switching program execution paths during runtime of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The method for dynamically switching program execution paths at runtime provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can load multiple execution paths for the same functional task at program startup and collect hardware capability information to determine the current execution path. During program execution, it continuously collects real-time hardware capability information, re-matches and determines the target execution path, and updates the current execution path identifier through a thread synchronization mechanism when the target execution path differs from the current execution path, ensuring the program always uses the execution path with the highest matching degree. This invention achieves adaptive switching of execution paths by sensing changes in hardware capabilities during runtime and dynamically updating the execution path without restarting, thereby reducing performance waste, avoiding service interruptions, and improving resource utilization efficiency and system stability. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The following detailed description of specific embodiments further illustrates this invention.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the method for dynamically switching program execution paths at runtime provided by the present invention. It should be noted that although the logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0015] like Figure 2 As shown, the method for dynamically switching program execution paths at runtime proposed in this invention includes the following steps: S10, when the program starts, load multiple different versions of execution paths for the same functional task to form an execution path set, and generate execution path description information containing hardware capability requirements for each execution path in the execution path set. In this embodiment, a loading action is performed upon program startup to introduce multiple different versions of execution paths for the same functional task into a callable state. The same functional task ensures consistency in input / output semantics and computational results across multiple execution paths; its source can be the same interface constraint or the same entry point, ensuring that differences between versions are only reflected in implementation details. Multiple different versions of execution paths represent code entities customized for different hardware conditions; their source can be different compilation artifacts, different instruction set extension enabling configurations, or different vectorized implementations. Loading locates the entry point of each execution path in the program-accessible address space; the entry point can be determined through static symbol resolution, dynamic library symbol resolution, or initialization registration. The execution path set carries all loaded execution paths; its representation can be an iterable container structure, enabling unified management of execution paths later. Execution path description information is generated for each execution path in the execution path set to explicitly associate the execution path with hardware capability requirements. The execution path description information serves as a record unit corresponding one-to-one with the execution path and includes at least a hardware capability requirement field. Hardware capability requirements express the processor capability boundaries needed for an execution path to run. These requirements can originate from capability tags generated during the build phase or capability tags configured during the deployment phase. The generation action is used during the loading phase to bind execution paths to hardware capability requirements, ensuring that each execution path within the execution path set has a directly readable capability description.

[0016] Multiple execution paths of different versions can be compiled into different symbolic entry points within the same program. At program startup, an initialization function adds each entry point to the execution path set and constructs corresponding execution path description information for each entry point, writing the hardware capability requirements into it. Alternatively, multiple execution paths of different versions can be placed in multiple shared libraries. At program startup, the shared libraries are loaded sequentially, the entry symbols are parsed and added to the execution path set, and the hardware capability requirements are read from the configuration items and written into the execution path description information. The execution path set can also be implemented as an array structure to reduce traversal overhead, or as a key-value structure for organization and storage by capability tags.

[0017] This embodiment loads multiple execution paths and synchronously generates execution path description information containing hardware capability requirements when the program starts. This ensures that each execution path has a clear capability boundary description in the execution path set, reduces the implicit dependency between execution paths and hardware conditions, and improves the determinism of execution path organization and management.

[0018] S20, when the program starts, collect the initial hardware capability information of the current operating environment; In this embodiment, a data acquisition action is performed upon program startup to obtain hardware capability information of the current operating environment at the moment of startup. The current operating environment defines the processor instance where the program actually runs; its source can be a physical machine processor or processor resources mapped from a virtualized environment. Initial hardware capability information describes the stable processor capability state that the operating environment can provide during startup, primarily focusing on processor instruction-level capabilities. The acquisition action is completed by triggering processor capability identification instructions, defined by the processor architecture, used to return status data related to functional extensions. After executing the identification instruction, the processor returns a set of functional characteristic register values, which encode the support for different instruction sets or extended capabilities in bit-level form. The parsing process extracts valid capability flag bits from the functional characteristic register values, filtering out capability information related to execution path adaptation. The encoding process combines the extracted capability flag bits according to a unified bitmask format to form structurally stable and comparable initial hardware capability information, thereby providing basic data for subsequent capability matching.

[0019] At the program initialization entry point, processor identification instructions can be invoked to obtain the contents of the feature registers, and initial hardware capability information can be generated by extracting instruction set support flags through bitwise operations. Alternatively, equivalent capability flags can be obtained through the hardware capability query interface provided by the operating system and then converted into a unified bitmask format. Furthermore, in virtualization or container environments, the host machine-exposed capability information can be combined with local identification results for encoding to adapt to different deployment environments.

[0020] This embodiment obtains and encodes the initial hardware capability information of the current operating environment during the program startup phase, so that the subsequent execution path selection is based on clear and quantifiable capability data, avoiding the execution path selection from relying on uncertain implicit environmental assumptions.

[0021] S30, based on the initial hardware capability information and the execution path description information, determine the initial execution path with the highest matching degree with the initial hardware capability information from the execution path set, and configure the identifier of the initial execution path as the current execution path identifier; In this embodiment, after obtaining the initial hardware capability information, the execution path selection process is triggered to determine the most suitable execution path for the current runtime environment from multiple loaded execution paths. The initial hardware capability information describes the instruction-level capabilities the processor can provide at program startup, while the execution path description information describes the hardware capability conditions that each execution path depends on during the compilation or build phase. The matching process is completed by comparing the capability representations of the two. The initial hardware capability information represents the set of capabilities already possessed by the processor in bitmask form, and the execution path description information represents the set of capabilities required for the corresponding execution path to run in bitmask form. The matching degree is determined through bitwise logical operations, i.e., performing a bitwise logical AND operation between the initial hardware capability information and the capability requirements corresponding to each execution path, and then verifying the numerical consistency between the calculation result and the capability requirements of the execution path to determine whether the runtime environment fully covers the capability requirements of the execution path. Only when the runtime environment capabilities fully meet the execution path capability requirements is the execution path considered a usable execution path. When multiple usable execution paths exist simultaneously, they are sorted according to a predefined performance priority relationship, and the one with the highest performance level is selected as the initial execution path. The identifier of the initial execution path is used to uniquely point to the entry point of the execution path. This identifier is written to a globally accessible storage location to establish the current execution path identifier that is uniformly referenced when the program is called subsequently.

[0022] During program initialization, the execution path set can be traversed, reading the capability requirement field from the execution path description information one by one. A bitwise logical AND operation can be performed with the initial hardware capability information to filter out execution paths with perfectly matching capabilities. Then, one of these paths can be selected as the initial execution path based on performance priority. Alternatively, the capability level order can be pre-maintained in the execution path description information. During traversal, the matching is verified sequentially from highest to lowest capability level. Once a matching execution path is found, the selection is complete, and the corresponding entry address is written to the current execution path identifier. Furthermore, the execution path description information can be organized into a data structure grouped by capability level to reduce the number of matching calculations.

[0023] This embodiment completes the matching calculation based on hardware capability information and execution path description information and configures the current execution path identifier during the program startup phase. This allows the program to automatically bind to the execution path that best matches the capabilities of the runtime environment when it runs for the first time, reducing the operational risks caused by capability mismatch and improving the certainty of execution efficiency.

[0024] S40, during program execution, respond to monitoring trigger conditions and collect real-time hardware capability information of the current operating environment; In this embodiment, after the program enters the running state, continuous monitoring of hardware capability status is required to address potential changes in the operating environment. The operating environment may experience capability differences over time due to task migration, resource reallocation, or changes in underlying nodes. Therefore, monitoring trigger conditions are set to control the timing of data collection and avoid the overhead of frequent collection. Monitoring trigger conditions can consist of time factors, scheduling events, or state change signals. When the monitoring trigger conditions are met, the hardware capability collection process is initiated. Real-time hardware capability information characterizes the actual available instruction set capability status of the processor at the current moment. Its expression format remains consistent with the initial hardware capability information to ensure the reusability of subsequent comparison logic. The collection process is completed by reading the processor capability register or equivalent capability interface, and the reading results are converted into a unified capability representation according to predetermined encoding rules, thereby forming real-time hardware capability information that can be used for subsequent decision-making.

[0025] Independent monitoring execution units can be created during program execution to periodically determine whether monitoring trigger conditions are met, and perform hardware capability reading operations when the conditions are met. Alternatively, the acquisition logic can be directly triggered when a system event indicating a change in the operating environment is detected, such as a scheduling notification or a resource binding change signal. Time-triggered and event-triggered methods can also be combined to reduce the frequency of invalid acquisitions while ensuring timely response.

[0026] This embodiment collects real-time hardware capability information based on monitoring trigger conditions during program execution, enabling timely detection of changes in hardware capabilities during operation. This provides a reliable data foundation for subsequent execution path adjustments and avoids maintaining an incompatible execution state for a long time due to changes in hardware capabilities.

[0027] S50, based on the real-time hardware capability information and the execution path description information, determine the target execution path with the highest matching degree with the real-time hardware capability information from the execution path set; In this embodiment, after obtaining real-time hardware capability information, it is necessary to perform correlation analysis between this information and the established execution path description information to determine the execution path with the highest degree of compatibility under the current operating conditions. Real-time hardware capability information reflects the actual available instruction set capabilities of the processor at the current moment, while execution path description information describes the instruction set capability requirements of each execution path. The matching degree is calculated based on capability satisfaction relationships. By comparing the hardware capability requirements in the real-time hardware capability information and the execution path description information one by one, it is determined whether the current hardware state fully covers the capability requirements of the corresponding execution path. When multiple execution paths meet the capability requirements, a performance priority rule is introduced to rank the execution paths that meet the conditions. This further distinguishes performance differences under the premise of capability compatibility, ultimately determining the target execution path with the highest matching degree to the real-time hardware capability information. This process ensures that the target execution path is executable at the capability level and has a relative advantage at the performance level.

[0028] Real-time hardware capability information can be logically processed against the capability requirements of each execution path, and compatibility can be determined by the consistency between the result and the capability requirements. Alternatively, a step-by-step verification of capability fields can be used, and the corresponding execution path can be included in the candidate range after all capability conditions are met. For execution paths within the candidate range, they can be compared based on pre-defined performance level identifiers, and the execution path with the highest level can be selected as the target execution path.

[0029] This embodiment dynamically matches real-time hardware capability information with execution path description information, enabling the target execution path to adjust as the operating environment changes. This avoids long-term mismatch between the execution path and hardware capabilities, thereby improving the overall execution efficiency during the operation phase.

[0030] S60, compare the identifier of the target execution path with the identifier of the current execution path, and when the identifier of the target execution path is inconsistent with the identifier of the current execution path, use the thread synchronization mechanism to update the identifier of the current execution path to the identifier of the target execution path.

[0031] In this embodiment, after determining the target execution path, a consistency check of the current execution state is required to determine whether an execution path switch is necessary. The target execution path identifier indicates the optimal execution entry point calculated in the current runtime environment, while the current execution path identifier indicates the execution entry point actually used by the program at this moment. By directly comparing the two types of identifiers at the numerical level, it can be determined whether they point to the same execution entry point. When the comparison results show consistency, it means that the current execution state is already in the optimal configuration, and no additional concurrency control operations are needed; when the comparison results show inconsistency, it means that changes in the runtime environment have caused the original execution entry point to no longer be optimal, and a safe update of the execution entry point is required.

[0032] During the update process, a thread synchronization mechanism is introduced to control concurrent access behavior. This mechanism coordinates the order of access to the shared execution path identifier in a multi-threaded environment, ensuring that reads and writes do not overlap during the update of the execution entry point. By granting write permissions during the update phase, the modification of the execution path identifier is guaranteed to be temporally exclusive, thus preventing threads from reading incomplete or inconsistent entry information during thread switching. The update of the execution path identifier is completed in a single, full write operation, making the new execution entry point logically effective for all threads simultaneously.

[0033] During the comparison phase, the value of the current execution path identifier can be directly read and compared with the target execution path identifier for equivalence. After confirming the need for an update, exclusive access can be acquired through a mutex or read-write lock in write mode. While holding this access, the target execution path identifier is written to the global storage location used to store the current execution path identifier. Synchronization control is released immediately after the update, allowing subsequent threads to automatically obtain the new execution entry point when reading the execution path identifier. Alternatively, other synchronization primitives with equivalent synchronization semantics can be used to achieve the same access control.

[0034] This embodiment performs a consistency check on the identifier before switching execution paths and introduces thread synchronization control during the update phase, so that the switching process of the execution entry point remains atomic and predictable in a concurrent environment, thereby avoiding entry point confusion or thread competition problems during execution.

[0035] In one embodiment, step S10 includes: S101, for the same functional task, obtain multiple different versions of execution paths that are adapted to different instruction set architectures, and determine the entry address in memory for each execution path; S102, Define a path descriptor structure for carrying execution path description information, the path descriptor structure includes a function pointer field and a capability mask field for storing hardware capability requirements; S103, instantiate the path descriptor structure for each execution path, assign the entry address to the function pointer field, and assign the hardware capability requirements corresponding to the execution path to the capability mask field to generate execution path description information; S104, store all the generated execution path description information into the global path registry to form an execution path set.

[0036] In this embodiment, during the program startup phase, the same functional task needs to be split into multiple replaceable execution entry points, and the preconditions for each execution entry point are explicitly encoded into comparable data entries, forming an enumerable and indexable set of execution paths. Here, the same functional task refers to a computational unit that presents the same input-output contract, such as the same matrix multiplication interface, the same convolution operator interface, or the same image filtering interface. An execution path refers to the specific implementation branch that completes the functional task. Under the premise of semantic consistency, different versions of execution paths are allowed to use different instruction set architectures, instruction sequences, register allocation methods, vector widths, and pipeline organization methods, thereby achieving different performance under different hardware conditions. The instruction set architecture is used to characterize the set of instruction extensions available to the processor. Multiple different versions of execution paths can correspond to different instruction extension levels or different microarchitectural constraints, avoiding binding the implementation to a single hardware capability.

[0037] When obtaining multiple execution paths adapted to different instruction set architectures, multiple target binary units can be generated during the build phase, or the corresponding implementation can be loaded from multiple compiled artifacts during the startup phase. Each execution path needs a stable entry symbol and a callable function signature. The entry address uniquely points to the starting location of the execution path in memory. The entry address can be determined through the linker's symbol resolution, the symbol lookup interface of dynamically loaded modules, or by writing the entry symbol address into the initialization table during compilation. The type of the entry address needs to be consistent with the calling convention of the functional task to avoid call stack corruption or parameter resolution errors caused by mismatched function pointer types. After the entry address is determined, a one-to-one correspondence between the entry address and the corresponding execution path version should be maintained to ensure that different versions are not confused during subsequent registration and retrieval.

[0038] To bind the execution entry point and runtime prerequisites within the same data structure, a path descriptor structure is introduced as the carrying unit. The path descriptor structure is used to fix field boundaries, clarify field semantics and alignment, and avoid parsing ambiguity caused by loose key-value pairs. The function pointer field stores the entry address; the pointer type in the function pointer field needs to include parameter list and return value type information to ensure consistent indirect calls at a unified call point. The capability mask field stores the encoded results of hardware capability requirements, which refer to the set of processor capabilities required for the normal operation of the execution path, such as specific vector instruction extensions, specific bit width support, and specific register state support. The capability mask field uses bitmasking to compress multiple capability requirements into fixed-width integers, enabling fast inclusion judgment through bitwise operations and maintaining scalable expression for different capability combinations. The bit definitions of the capability mask field need to remain consistent during compilation and runtime to ensure that the same bit expresses the same hardware capability meaning in different modules.

[0039] When instantiating a path descriptor structure for each execution path, the entry address needs to be assigned to the function pointer field, and the hardware capability requirements corresponding to the execution path need to be assigned to the capability mask field, thereby generating the execution path description information. The instantiation process should ensure that each structure entry is stored independently to avoid multiple entries sharing variable memory and causing writes to overwrite each other. The assignment of hardware capability requirements can come from static annotations during the build phase, or from compilation artifact metadata or configuration table mappings, but it is necessary to ensure that the annotation results are consistent with the actual instruction extensions used within the execution path to avoid insufficient annotation in the capability mask field, which could lead to the selection of an entry point that does not meet the conditions at runtime. After generating the execution path description information, the function pointer field and the capability mask field form a strong binding relationship, encapsulating the callability and runnable prerequisites of the execution path at the data level.

[0040] When storing all execution path descriptions in a global path registry to form an execution path set, the global path registry assumes the responsibility of unified indexing and enumeration. The global path registry can use a contiguous array to support traversal by index, a hash table to support retrieval by version identifier, or a data structure bucketed by capability level to support fast filtering. Writing to the global path registry occurs during program startup. After writing, the structure can be set to read-only or frozen state to reduce the need for registry modifications during runtime and lower the complexity of concurrent access. Once the execution path set is formed, it possesses stable content boundaries and iterability, allowing any subsequent selection-related operations to be performed based on the same set semantics, using the execution path description information as the sole input to complete capability matching and entry point location.

[0041] This embodiment establishes a structured binding between entry addresses and hardware capability requirements for multiple different versions of the same functional task execution paths, and centrally stores them in a global path registry to form an execution path set. This transforms execution entry management from scattered conditional branches and symbolic references into an enumerable set of data entries, reducing ambiguity in entry location and capability constraint expression, improving the scalability and maintainability of execution path versions, and providing a fixed-format data foundation for subsequent rapid matching based on capability masks, thereby reducing parsing overhead and implementation coupling in the selection process.

[0042] In one embodiment, step S20 above includes: S201, during the initialization phase of the program startup, the processor identification instruction of the underlying processor in the current running environment is invoked; S202, Read the value of the functional characteristic register returned after executing the processor identification instruction; S203, parse the value of the function feature register and extract the instruction set support flag bit representing the processor's extended function features from the value of the function feature register; S204, the extracted instruction set support flags are encoded according to a preset bitmask format to generate initial hardware capability information.

[0043] In this embodiment, the program startup phase needs to generate initial hardware capability information that can be used for subsequent execution path selection. The initialization phase of program startup is used to define the collection time point. The initialization phase corresponds to the execution interval after the process is loaded and before the unified call entry point begins processing business requests. The collection during the initialization phase can ensure that the initial hardware capability information corresponds semantically with the current running environment at the same moment, avoiding missing or inconsistent capability information before subsequent control logic is established. The current running environment includes the processor capability exposure results of the host machine or virtualization carrier where the process is located, the enabled state of the operating system for instruction extensions, and the set of hardware characteristics visible to the thread context. Here, the objects collected are limited to the enumerable functional characteristics of the underlying processor, ensuring that the initial hardware capability information has a repeatable and comparable source.

[0044] The processor identification instruction, invoked from the underlying processor in the current runtime environment, triggers the processor to output a structured capability description. This processor identification instruction is a self-describing interface provided by the processor, returning characteristic bit information consistent with the hardware without relying on external configuration tables. The invocation must be initiated in user space and completed through compiler inline assembly or architecture-built-in functions. Inline assembly is used to explicitly issue instruction codes, while architecture-built-in functions allow the compiler to generate the corresponding instruction sequence and return register contents. The processor identification instruction invocation must carry a function number or sub-function number to select the capability page to return. The function number selects the range of characteristic categories, while the sub-function number selects a finer-grained set of extended characteristics. The invocation of the processor identification instruction must consider serialization semantics, which ensures that the instruction has completed execution before reading registers, avoiding reading residual register states not present in the current call.

[0045] Reading the feature register values ​​returned after executing the processor identification instruction is used to convert the hardware output from register state to storable raw data objects. The feature register values ​​are bit vectors written to the register set after the processor identification instruction is executed. The register set typically contains multiple general-purpose register slots, each carrying a return fragment from a different feature page. The read operation needs to copy the values ​​of each register slot to local variables or buffers in a fixed order. This fixed order ensures that the register source of each bit can be determined during subsequent parsing. The storage width of the feature register values ​​needs to be consistent with the register width. Register widths may vary in different architectures; inconsistent storage widths can introduce high-order truncation or sign extension issues, leading to distortion in subsequent bit extraction. The read process also needs to handle combinations of multiple calls. When a capability set is distributed across multiple function number or sub-function number return pages, the read operation needs to maintain an independent feature register value record for each return page so that pages can be merged during the parsing phase.

[0046] Parsing the values ​​in the feature registers transforms the raw bit vector into semantically meaningful instruction set support (ISS) flags. The parsing process establishes a mapping between bits and extended features, specifying whether a particular bit in a register represents the availability of a specific processor ISS. This mapping can originate from feature bit definitions in the processor architecture specification or from a capability bit table specific to a compilation target. However, the mapping must be consistent with the function number and sub-function number of the processor-identified instruction; otherwise, irrelevant bits will be interpreted as target bits. Parsing involves shifting and bitwise AND operations on the feature register values. Shifting moves the target bit to the least significant bit, and bitwise AND masks non-target bits, resulting in a binarized result. The ISS flags are the output set of the parsing phase, indicating that a particular ISS is visible in the current runtime environment and can be decoded and executed by instructions. Instruction set support flags not only cover the instruction set extensions themselves, but also the context support conditions related to the instruction extensions, such as whether the operating system allows saving the state of extended registers, and whether thread context switching supports the relevant register sets. These conditions can be obtained by resolving the relevant bits of the processor-identified instruction or the additional capability pages, so that the instruction set support flags express runtime availability rather than just hardware presence.

[0047] The extracted instruction set support flags are encoded according to a preset bitmask format to compress the discrete flag set into a unified representation of initial hardware capability information. The preset bitmask format assigns fixed mask bit positions to each type of processor extended feature. These bit positions are used to express whether the extended feature is satisfied within an integer or a bit array. The preset format means that the bit position allocation remains consistent during compilation and runtime to ensure subsequent bitwise logical operations with hardware capability requirements. The encoding process maps each instruction set support flag to its corresponding mask bit and aggregates multiple mask bits into a single mask value using a bitwise OR operation. The bitwise OR operation combines the satisfaction states of multiple independent conditions into a parallel-computable bit vector. The initial hardware capability information is the output of the encoding phase. This information can use fixed-length integers, expandable bit arrays, or segmented mask structures. Fixed-length integers provide lower access costs when the capability set size is fixed; expandable bit arrays prevent insufficient bit width when the capability set continues to expand; and segmented mask structures store the bit fields of different capability pages in segments to reduce cross-page merging complexity. Once the initial hardware capability information is generated, it needs to maintain immutable semantics or at least be frozen during the initialization phase to prevent subsequent logic from rewriting the object without synchronization, which could cause the initial judgment benchmark to drift.

[0048] This embodiment calls the processor identification instruction of the underlying processor and reads the value of the function characteristic register during the initialization phase of program startup. The function characteristic register value is parsed into instruction set support flag bits, and then encoded according to a preset bitmask format to generate initial hardware capability information. This can solidify the available hardware capabilities in a unified and computable bit vector form, so that subsequent matching of hardware capability requirements can directly reuse the initial hardware capability information for bitwise operations and numerical comparisons, reducing dependence on text configuration or external probing links, and reducing ambiguity and parsing overhead in the capability judgment process.

[0049] In one embodiment, step S30 above includes: S301, Obtain the preset performance priority rules for the set of execution paths; S302, perform a bitwise logical AND operation on the initial hardware capability information and the hardware capability requirements contained in the description information of each execution path in the execution path set to obtain a logical operation result corresponding to each execution path. S303, compare the numerical equality of each logical operation result with the hardware capability requirements in the corresponding execution path description information, and identify all execution paths with equal comparison results as available execution paths that can be satisfied by the initial hardware capability information; S304, Based on the performance priority rules, determine the execution path with the highest priority level from all available execution paths as the initial execution path; S305, obtain the entry address of the initial execution path, and assign the entry address as the identifier of the initial execution path to the global pointer variable, so as to configure the global pointer variable as the identifier of the current execution path.

[0050] In this embodiment, when initial hardware capability information and execution path description information are used to determine the initial execution path, a unified selection criterion needs to be established first, so that the "highest matching degree" has a calculable and verifiable judgment standard. Performance priority rules are used to assign comparable hierarchical relationships to different execution paths within the execution path set. Performance priority rules can be implemented using a constant table, an enumerated level mapping table, or preset values ​​of fields within the path descriptor. When implementing a constant table, different instruction extension capabilities are mapped to discrete level values, and a level value is recorded for each execution path in the execution path description information, so that after subsequent screening to obtain available execution paths, the maximum level value can be directly selected. When implementing an enumerated level mapping table, the mask pattern of hardware capability requirements is mapped to priority levels, avoiding complex derivations at runtime. When implementing fields within the path descriptor, the priority level is registered as part of the execution path description information along with the execution path to the execution path set, reducing external dependencies and ensuring that rules evolve synchronously with path versions. Performance priority rules need to remain deterministic, outputting the same initial execution path when the same initial hardware capability information is input. Determinism depends on the total order definition of priority levels and conflict resolution strategies. For example, if the levels are the same, they can be sorted in a fixed order based on the entry address or the registration order, thereby avoiding random binding during multiple startups.

[0051] After defining the selection criteria, the question of "whether the hardware meets the path requirements" needs to be transformed into a strict Boolean decision. Initial hardware capability information and hardware capability requirements are expressed using bitmasks. A bitwise AND operation is used to calculate the bit intersection of the initial hardware capability information and the hardware capability requirements. Performing the bitwise AND operation one by one emphasizes a one-to-one correspondence. Each execution path description in the execution path set corresponds to one bitwise AND operation. The input to the bitwise AND operation is fixed as the initial hardware capability information and the hardware capability requirements of the current execution path description information, and the output is fixed as the logical operation result. The logical operation result needs to be saved as intermediate data or immediately used for comparison. The saving method can be a temporary registered variable, an array slot, or directly written back to the cache field of the execution path description information. When implementing the cache field, the logical operation result can be used as a one-time verification product to avoid repeated calculations. The "one by one" here also requires stability during traversal. The traversal of the execution path set can be based on a linear array, linked list, or hash table iterator of the global path registry. Linear arrays are convenient for maintaining the registration order and reducing traversal costs. Linked lists are convenient for dynamically plugging and unplugging paths but require additional handling of concurrent read consistency. Hash tables are convenient for quickly locating by capability category but still need to ensure full coverage to complete the identification of available execution paths.

[0052] The result of a logical operation cannot directly represent the fulfillment of a relationship; a numerical equality comparison is needed to distinguish between "partial coverage" and "complete coverage." The numerical equality comparison uses the equality of the logical operation result with the hardware capability requirement as the criterion. Only when the logical operation result equals the hardware capability requirement does the initial hardware capability information include all the capability bits required by the hardware capability requirement. The numerical equality comparison is used to exclude cases where only some capability bits are hit, avoiding misclassifying execution paths requiring multiple bits of joint support as usable execution paths. At the implementation level, two integer mask values ​​can be directly compared, or each segment can be compared separately under a segmented mask structure, with full segment and merge determinations performed. Segmented comparison is used to expand the capability bit width while keeping the comparison cost linearly controllable. Execution paths with equal comparison results need to be identified as usable execution paths. Usable execution paths can be written with Boolean flags in their description information, or their indices can be written to a temporary list. Alternatively, during traversal, available execution paths can be maintained online according to their priority levels. Boolean tagging facilitates subsequent one-time scanning and filtering, indexed list method helps reduce the scope of subsequent traversal, and online maintenance method helps reduce additional storage and integrate filtering and selection. However, online maintenance still needs to maintain the traceability of the "one-to-one" judgment process, which is usually achieved by simultaneously saving the level value and entry address of the current best candidate.

[0053] After obtaining the semantics of the available execution path set, the execution path with the highest priority level needs to be selected from all available execution paths according to the performance priority rule and determined as the initial execution path. Here, "according to the performance priority rule" requires that the selection logic can only rely on the level relationship given by the rule, and should not introduce external conditions unrelated to the matching, avoiding the introduction of unpredictable biases. Determining the highest priority level can be achieved by performing a maximum value scan on the available execution paths. During the maximum value scan, the priority level of each available execution path is read, and the current maximum level and corresponding entry address are maintained. Alternatively, the maximum level can be maintained synchronously during the aforementioned comparison phase, so that the initial execution path can be directly obtained at the end of the traversal. The maintenance method needs to ensure that it only participates in the maximum value update when the comparison results are equal, avoiding unavailable execution paths polluting the maximum value. It is also necessary to handle the case where there are no available execution paths. The execution path set usually contains a fallback execution path with empty or minimum hardware capability requirements. When the hardware capability requirements of the fallback execution path are encoded as a zero mask, they can be satisfied by any initial hardware capability information, thus ensuring that the initial execution path is always determinable and guarantees startup executability.

[0054] Once the initial execution path is determined, its identifier needs to be configured as the current execution path identifier to complete the entry point binding during subsequent unified calls. The entry point address points to the executable entry point of the initial execution path in memory. This can be a function entry point address, a jump stub entry point address, or an indirect call table entry address. The entry point address is obtained from the function pointer field or equivalent field recorded in the execution path description information. Using the entry point address as the identifier of the initial execution path emphasizes the consistency between the identifier and the actual callable entry point, avoiding the need for a secondary table lookup due to using an abstract number as the identifier. A global pointer variable is used to carry the current execution path identifier. The global pointer variable needs to have intra-process visibility so that concurrent threads can read the same current execution path identifier to complete consistent call routing. The assignment operation writes the entry point address to the global pointer variable. During writing, aligned writes can be used to reduce the risk of code tearing, or in a multi-threaded environment, memory order semantics can be used to ensure that the entry point address read by other threads is consistent with the corresponding code segment. Once the current execution path identifier is configured, any subsequent call chain that reads global pointer variables will place the call in the initial execution path, achieving the goal of binding the execution path according to hardware capabilities during the startup phase and reserving a consistent state anchor point for runtime switching.

[0055] This embodiment explicitly defines the performance level of execution paths by introducing performance priority rules. Then, it performs a bitwise logical AND operation on the hardware capability requirements of each execution path description information and the initial hardware capability information in the execution path set, and compares the numerical equality. This enables the identification of available execution paths to be based on the complete coverage criterion, avoiding misselection caused by partial matching. Within the range of available execution paths, the execution path with the highest priority level is determined according to the performance priority rules, and the entry address is written into a global pointer variable to form the current execution path identifier. This makes the execution path binding in the startup phase have deterministic, verifiable, and low-overhead direct call entry points, thereby reducing the lookup cost during subsequent calls and reducing ambiguity in execution path selection.

[0056] In one embodiment, step S40 above includes: S401 creates and starts an independently running background monitoring thread in the program process and sets the monitoring time interval; S402, control the background monitoring thread to enter a sleep state to pause execution; S403, when the duration of the background monitoring thread in the sleep state reaches the monitoring time interval, the background monitoring thread is awakened, wherein the expiration of the monitoring time interval constitutes a monitoring trigger condition. S404, using a background monitoring thread that is in a woken-up state, performs a hardware information reading operation for the current operating environment to collect real-time hardware capability information.

[0057] In this embodiment, a repeatable data acquisition chain is required during program execution. Monitoring trigger conditions bind runtime acquisition actions to a time scale, ensuring that real-time hardware capability information is refreshed at a stable frequency and reflects changes in the current operating environment. When an independently running background monitoring thread is created and started within the program process, the thread creation process includes binding the thread entry function, configuring thread runtime attributes, and confirming thread startup. The thread entry function maintains a loop execution framework, which includes at least waiting logic and acquisition logic. Independent operation emphasizes the decoupling of the background monitoring thread from the business execution thread. The lifecycle of the background monitoring thread is consistent with the program process or the acquisition requirements, avoiding embedding acquisition actions into the business call path and introducing additional blocking. The monitoring time interval defines the duration of the waiting logic. The monitoring time interval can be expressed as a millisecond-level time value, system tick count, or monotonic clock difference. The storage location of the monitoring time interval can be a thread-private variable or a global configuration slot. Thread-private variables reduce concurrent write interference, while global configuration slots are used to dynamically adjust the acquisition frequency during runtime. The determination of the monitoring time interval needs to be adapted to the rate of change of real-time hardware capability information. When the rate of change is low, a larger monitoring time interval is selected to reduce the frequency of thread wake-up, and when the rate of change is high, a smaller monitoring time interval is selected to shorten the detection latency.

[0058] When the background monitoring thread enters a sleep state to pause execution, the sleep state corresponds to the implementation of waiting logic, which can be implemented through sleep system calls, condition variable waiting, or timer event waiting. When implemented with a sleep system call, the background monitoring thread converts the monitoring time interval into a sleep parameter and yields processor time slices, suitable for time-driven triggering conditions. When implemented with a condition variable waiting, the background monitoring thread holds a mutex and enters a waiting queue. Waiting can be triggered by timeout expiration or by external signals, thus maintaining the semantics of the monitoring time interval while being compatible with additional triggering sources. When implemented with a timer event waiting, the background monitoring thread registers a periodic timer and blocks on the event acquisition interface. The timer delivers the event to the thread upon expiration, reducing scheduling jitter caused by active polling. After entering a sleep state, the background monitoring thread does not perform hardware information reading operations, avoiding repeated sampling within the waiting window that could lead to excessively high data density or uncontrolled coverage frequency.

[0059] A clear causal relationship needs to be established between the background monitoring thread being awakened and the monitoring trigger condition. When the expiration of the monitoring time interval constitutes the monitoring trigger condition, the expiration determination relies on a monotonic clock or a timer expiration event. The monotonic clock is used to avoid interval calculation errors caused by system time rollback. The duration when the monitoring time interval is reached can be calculated by subtracting the time of entering the sleep state from the wake-up time, or by directly driving the wake-up using the kernel timer expiration callback. Being awakened means that the background monitoring thread resumes execution from the sleep state and enters the acquisition logic. The entry point of the acquisition logic and the exit point of the waiting logic are adjacent in the control flow, ensuring that hardware information reading operations begin immediately after the monitoring trigger condition is triggered, reducing the latency from triggering to acquisition.

[0060] Hardware information reading operations are used to convert the hardware capability status of the current operating environment into a comparable data representation and form real-time hardware capability information. Hardware information reading operations must ensure consistency in encoding, ensuring that the real-time hardware capability information and the initial hardware capability information are isomorphic in bit meaning, field layout, and masking rules. This allows subsequent matching calculations to reuse the hardware capability requirements described by the same execution path without causing caliber drift. Hardware information reading operations can be implemented by reading registers and parsing capability bits through processor capability probe instructions, or by reading the capability bit set through the hardware capability query interface provided by the operating system. The capability bit set is then encoded into a bitmask format to form real-time hardware capability information. To prevent the collected results from being overwritten midway, the background monitoring thread needs to first generate a temporary copy of the real-time hardware capability information within a collection cycle, and then write the copy to the storage location of the real-time hardware capability information. The storage location can be a private cache of the background monitoring thread and passed to subsequent logic through a message queue, or a shared memory slot with write order control to ensure that the reader sees complete data. After collection is complete, the background monitoring thread returns to the waiting logic and enters a sleep state again, forming a stable collection closed loop with a monitoring time interval as the cycle.

[0061] This embodiment maintains an independently running background monitoring thread within the program process and drives the cyclical switching between sleep and wake-up states at monitoring intervals. The monitoring trigger condition is constrained to the expiration of the monitoring interval, thereby transforming runtime data collection into a controllable periodic refresh. After waking up, the background monitoring thread performs hardware information reading operations and generates real-time hardware capability information. The real-time hardware capability information maintains the same encoding standard as the initial hardware capability information, enabling the real-time hardware capability information to stably reflect changes in the hardware capabilities of the current operating environment and provide a continuous and comparable data foundation for subsequent path matching.

[0062] In one embodiment, step S60 above includes: S601, Read the current value of the current execution path identifier, and compare the identifier of the target execution path with the current value of the current execution path identifier; S602, if the comparison result shows that the identifier of the target execution path is inconsistent with the identifier of the current execution path, request the operating system to acquire a mutex write lock belonging to the thread synchronization mechanism to block other threads in the program from concurrently reading the identifier of the current execution path; S603, in the state of successfully acquiring the mutex write lock, the identifier of the target execution path is assigned to the global pointer variable storing the identifier of the current execution path, so as to update the identifier of the current execution path to the identifier of the target execution path; S604, release the mutex write lock to unblock the concurrent read operation, so that subsequent program calls can access the target execution path through the updated current execution path identifier.

[0063] In this embodiment, comparing the identifier of the target execution path with the identifier of the current execution path is used to confirm the necessity of switching. The comparison action is based on shared state reading. When reading the current value of the current execution path identifier, a comparable value copy needs to be obtained from the global pointer variable storing the current execution path identifier. The value copy is used to participate in subsequent value comparisons and avoids being interrupted by concurrent writes during the comparison. The value comparison uses equality judgment to express consistency. When the identifier of the target execution path is consistent with the current value of the current execution path identifier, the switching action does not occur, avoiding invalid lock requests that cause thread scheduling overhead and lock contention amplification. When the identifier of the target execution path is inconsistent with the current value of the current execution path identifier, the synchronization update link is entered.

[0064] In this thread synchronization mechanism, the serialization of writes and the mutual exclusion of reads and writes are handled. The mutex write lock, as a specific lock form of the thread synchronization mechanism, is acquired and its acquisition is bound to the critical section boundary. When requesting a mutex write lock from the operating system, the lock request enters the kernel or thread library's scheduling path. Successfully acquiring the mutex write lock means that write permission is granted and an exclusive interval is formed. Within the exclusive interval, concurrent read operations by other threads in the program on the currently executed path identifier must be blocked. The blocked object is the read path identified by the currently executed path identifier. The read path may come from the read lock acquisition within the unified call interface or the call point directly reading the global pointer variable. The exclusive semantics of the mutex write lock require these read paths to pause within the write window to eliminate the possibility of reading an intermediate updated value.

[0065] Upon successfully acquiring the mutex write lock, an assignment operation is performed. This assignment writes the identifier of the target execution path to a global pointer variable that stores the identifier of the current execution path. The global pointer variable acts as the carrier of the current execution path identifier. After the assignment operation is completed, the semantics of the current execution path identifier are switched to the identifier of the target execution path. To ensure that the write operation is visible to subsequent reads, the assignment operation must be performed within a critical section protected by the mutex write lock. Entry into the critical section is defined by acquiring the mutex write lock, and exit from the critical section is defined by releasing the mutex write lock. The acquisition and release of the mutex write lock simultaneously constitute the constraint boundary for write order and visibility, ensuring that the current execution path identifier read by subsequent threads after unblocking is consistent with the assignment result.

[0066] Releasing the mutex write lock terminates the exclusive interval and restores concurrent read capability. After the release action is completed, concurrent read operations that were previously blocked by the mutex write lock regain their execution opportunity. Subsequent program calls to read the current execution path identifier will point to the updated identifier, and then access the target execution path through the updated current execution path identifier. The release action should be completed immediately after the assignment action to avoid the lock holding time from increasing, which would lead to a decrease in throughput, and to avoid long-term lock holding causing thread starvation and scheduling queue accumulation.

[0067] This embodiment compares the target execution path identifier with the current execution path identifier and only initiates a mutex write lock-protected update when they are inconsistent. The switching action is restricted to necessary scenarios, and lock contention is compressed to the window where the switching occurs. The mutex write lock blocks concurrent read operations during the update, making the writing and reading of the global pointer variable mutually exclusive. The updated current execution path identifier completes the switching with a single assignment and achieves visibility convergence within the mutex boundary. Subsequent program calls that access the target execution path based on this avoid the risk of concurrent consistency caused by reading intermediate state identifiers.

[0068] In one embodiment, after step S60 above, the method further includes: S701 provides a unified calling interface that encapsulates the access logic for the current execution path identifier; S702, when a call request for the same functional task is received, a shared read lock belonging to the thread synchronization mechanism is acquired to allow multiple threads in the program to read the current execution path identifier at the same time, but to block write operations for the current execution path identifier. S703, upon successfully acquiring the shared read lock, read the current execution path identifier and call the execution path pointed to by the current execution path identifier to execute the same functional task; S704, after the same functional task is completed, the shared read lock is released to allow subsequent write operations targeting the current execution path identifier.

[0069] In this embodiment, after the target execution path identifier and the current execution path identifier are updated once, the unified invocation interface is used to combine the reading of the current execution path identifier, the indirect invocation of the execution path, and the concurrency control of the thread synchronization mechanism into a single entry point. Invocation requests only need to enter the unified invocation interface to complete the execution of the same functional task. The unified invocation interface encapsulates the current execution path identifier access logic, which covers three stages: reading the current execution path identifier, locating the execution path entry point based on the current execution path identifier, and triggering the execution path to execute the same functional task. The direct result of this encapsulation is that the access point of the current execution path identifier is converged within the unified invocation interface, reducing the concurrency dispersion caused by directly reading the current execution path identifier from other locations.

[0070] When a call request for the same functional task is received, a shared read lock is acquired as a read-side constraint in the thread synchronization mechanism. The acquisition of the shared read lock brings the call request into the scope of read-write mutual exclusion semantics. The shared read lock allows multiple threads to be in a read state simultaneously, thus allowing multiple threads in the program to read the current execution path identifier concurrently. The shared read lock blocks write operations; the blocked object is a write operation targeting the current execution path identifier, which originates from the update action of assigning the identifier of the target execution path to the global pointer variable storing the current execution path identifier. A mutual exclusion relationship is formed between the shared read lock and the mutex write lock. The mutual exclusion condition is provided by the thread synchronization mechanism, ensuring that write operations can only occur within a time window when there is no shared read lock holder, and read operations can only occur within a time window when there is no mutex write lock holder, thereby transforming concurrent access to the current execution path identifier into a controllable sequence of reads and writes.

[0071] Upon successfully acquiring the shared read lock, the current execution path identifier is read and an execution path call is triggered. The read operation requires obtaining a stable identifier value from the global pointer variable storing the current execution path identifier. Stability is guaranteed by the shared read lock, ensuring that the read operation will not concurrently intersect with the write operation. After the read is complete, the unified call interface uses the current execution path identifier as the indirect call entry point to call the execution path pointed to by the current execution path identifier to execute the same functional task. Here, the execution path represents a versioned implementation of the same functional task. The parameter binding and return value reception of the indirect call are handled by the unified call interface, decoupling the call semantics of the same functional task from the version differences of the execution path.

[0072] Once the same functional task is completed, the shared read lock is released. This release terminates the current thread's holding of read-side resources, allowing subsequent write operations targeting the current execution path identifier to enter the mutex write lock acquisition process and complete the update. The timing of the shared read lock release needs to be aligned with the completion of the same functional task to avoid the execution path entry point being switched due to write operations modifying the current execution path identifier during execution. After the shared read lock is released, new calls can again acquire the shared read lock to read the updated current execution path identifier, enabling the read side to automatically follow the write side's update results.

[0073] Example Explanation: Taking a high-performance vector computing library deployed in a container environment as an example, the library provides multiple execution paths for the same functional task. This same functional task can be a vector addition function (`vector_add`), or a computation interface with fixed input-output semantics such as matrix multiplication, convolution operators, or distance calculation. To enable the program to have multiple execution versions during startup, multiple execution paths for the same functional task are loaded at startup to form an execution path set. Different versions of the execution paths are optimized and compiled for different instruction set architectures, such as compiling multiple implementation functions for SSE4.2, AVX2, and AVX512. During the loading phase, the program determines the entry address in memory for each execution path. The entry address can come from the symbol address after static linking or from the dlsym resolution result after dynamic linking. Subsequently, a path descriptor structure is defined to carry the execution path description information. The path descriptor structure contains a function pointer field and a capability mask field for storing hardware capability requirements. The function pointer field carries the entry address and forms a callable indirect entry point, while the capability mask field expresses the execution path's dependency constraints on instruction set feature bits. For each execution path in the execution path set, a path descriptor structure is instantiated. The entry address is assigned to the function pointer field, and the hardware capability requirements corresponding to the execution path are assigned to the capability mask field to generate execution path description information. The hardware capability requirements can be represented bitwise as requiring extended features such as SSE4.2 bits, AVX2 bits, AVX512 bits, etc., or they can be expressed bitwise as a superposition of multiple features to be satisfied simultaneously. All generated execution path description information is written to the global path registry. The global path registry, as a centralized registration container within the process, not only retains the enumeration capability of the execution path set but also provides a stable data source for subsequent matching calculations.

[0074] During the initialization phase of program startup, when acquiring initial hardware capability information of the current runtime environment, the program calls the processor identification instruction of the underlying processor in the current runtime environment. The processor identification instruction can be CPUID or an equivalent processor feature enumeration instruction. The calling method can be inline assembly or encapsulated by compiler-defined functions. After the processor identification instruction is executed, it returns the value of the feature register. The feature register value can come from a combination of multiple registers, including basic feature bits, extended feature bits, and leaf information. The program reads the feature register value and completes the parsing. The parsing process maps the register bit fields to a set of instruction set support flags. For example, one bit is interpreted as an SSE4.2 support flag, another as an AVX2 support flag, and yet another as an AVX512 support flag. At the same time, operating system context storage capability-related bits and extended register storage capability-related bits can be included in the parsing conditions to avoid situations where the hardware supports the feature but it is not available in the runtime state. The parsed instruction set support flags are encoded according to a preset bitmask format. The bitmask format limits the position and width of each instruction set support flag in the encoding result. The encoded output forms the initial hardware capability information. The initial hardware capability information expresses the set of instruction set capabilities available in the current operating environment with a single value, which facilitates bitwise logical operations with hardware capability requirements.

[0075] When determining the initial execution path with the highest matching degree based on the initial hardware capability information and execution path description information, the program first obtains the pre-defined performance priority rules for the execution path set. These rules can exist in the form of a static constant table, a read-only configuration segment, or a compile-time generated table. The rules sort the execution path levels corresponding to different instruction set architectures; for example, placing AVX512 above AVX2, and AVX2 above SSE4.2. A base fallback level can also be set to cover the lowest capability environment. The program traverses the execution path set, reads the hardware capability requirements from the execution path description information for each execution path, and performs a bitwise logical AND operation between the initial hardware capability information and the hardware capability requirements, obtaining a logical operation result corresponding to each execution path. To avoid partial matching errors, the program compares the logical operation result with the corresponding hardware capability requirements for numerical equality. A successful numerical equality comparison means that the initial hardware capability information covers all characteristic bits of the hardware capability requirements; a failed comparison means that at least one characteristic bit is missing. The program identifies execution paths with equal comparison results as usable execution paths that can be satisfied by the initial hardware capability information. Within the range of usable execution paths, it determines the execution path with the highest priority according to performance priority rules as the initial execution path. After determining the initial execution path, the program obtains the entry address of the initial execution path and assigns it as the identifier of the initial execution path to a global pointer variable. The global pointer variable carries the current execution path identifier in a single shared location. The current execution path identifier is subsequently used as the indirect call entry point, thus completing the configuration of binding the initial execution path as the default execution entry point.

[0076] To continuously adapt to hardware changes during program execution, an independent background monitoring thread is created and started within the program process, with a monitoring interval set. This interval can be configured based on service load, switching sensitivity, and hardware drift frequency. The background monitoring thread enters a sleep state to pause execution. When the sleep state duration reaches the monitoring interval, the background monitoring thread is awakened, and the expiration of the monitoring interval constitutes the monitoring trigger condition. Once awakened, the background monitoring thread performs hardware information reading operations to collect real-time hardware capability information for the current operating environment. This hardware information reading operation can either invoke processor recognition instructions again and parse function characteristic register values, or, in a constrained environment, combine the characteristic interfaces exported by the operating system to complete the capability reading, as long as the final output of the real-time hardware capability information uses the same bitmask format as the initial hardware capability information. After acquiring real-time hardware capability information, the program determines the target execution path with the highest matching degree from the execution path set based on the real-time hardware capability information and the execution path description information. The determination of the target execution path reuses the hardware capability requirements and performance priority rules in the execution path description information, and continues to use bitwise logical AND operation and numerical equality comparison to identify available execution paths. Within the range of available execution paths, the execution path with the highest priority level is selected as the target execution path according to the performance priority rules, so that the target execution path and the real-time hardware capability information are consistent with the matching criteria.

[0077] Once the target execution path is generated, the program compares its identifier with the current execution path identifier. The current execution path identifier comes from the current value of the global pointer variable, while the target execution path identifier can be the entry address of the target execution path or a stable identifier value mapped from the entry address. If the comparison shows that the target execution path identifier and the current execution path identifier are inconsistent, the program uses a thread synchronization mechanism to update the current execution path identifier to the target execution path identifier. In this example, the thread synchronization mechanism employs read-write separation semantics using mutex write locks and shared read locks. At the start of the update operation, a mutex write lock belonging to the thread synchronization mechanism is acquired. The mutex write lock is used to block concurrent read operations of other threads on the current execution path identifier, thus limiting the writing of the global pointer variable to a mutually exclusive region. After successfully acquiring the mutex write lock, the target execution path identifier is assigned to the global pointer variable storing the current execution path identifier. Once the assignment is complete, the current execution path identifier is updated to the target execution path identifier, and then the mutex write lock is released to unblock the process. To enable concurrent invocation and switching of the same functional task, a unified invocation interface encapsulates the access logic of the current execution path identifier after the update action. Upon receiving a call request for the same functional task, this unified invocation interface acquires a shared read lock, a thread synchronization mechanism. The shared read lock allows multiple threads to simultaneously read the current execution path identifier and block write operations. After successfully acquiring the shared read lock, the current execution path identifier is read, and the execution path pointed to by the identifier is invoked to execute the same functional task. For example, the unified invocation interface `vector_add`, under read lock protection, reads a global pointer variable and indirectly calls the implementation function pointed to by the corresponding function pointer field. This ensures that the same functional task automatically falls on the highest priority execution path without changing the upper-level calling format. After the same functional task is completed, the shared read lock is released. The write side can then acquire the mutex write lock again and complete the next update, ensuring that the execution path selection and switching during runtime maintain consistent access semantics and controllable read-write relationships under concurrent conditions.

[0078] This embodiment centralizes the reading of the current execution path identifier and the indirect calls of the execution path at the same entry point through a unified calling interface. When a call request enters, a shared read lock is acquired and released after the same functional task is completed. Concurrent reading on the read side is allowed, while write operations are blocked. The current execution path identifier remains consistent during the execution of the same functional task, and write operations can only be updated within the window after the read lock is released. This forms a predictable read-write mutual exclusion relationship in multi-threaded concurrent scenarios, reduces the risk of inconsistent execution entry points caused by the interleaving of concurrent reads and writes, and maintains concurrent read capabilities under a load of more reads and fewer writes.

[0079] In one embodiment, an apparatus for dynamically switching program execution paths at runtime is provided, which corresponds one-to-one with the method for dynamically switching program execution paths at runtime described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the apparatus for dynamically switching program execution paths during runtime according to the present invention. The modules include an execution path registration module 10, a hardware capability acquisition module 20, an initial path decision module 30, a runtime hardware monitoring module 40, a dynamic path evaluation module 50, and an execution path switching control module 60. Detailed descriptions of each functional module are as follows: The execution path registration module 10 is used to load multiple different versions of execution paths for the same functional task to form an execution path set when the program starts, and to generate execution path description information containing hardware capability requirements for each execution path in the execution path set. The hardware capability acquisition module 20 is used to acquire the initial hardware capability information of the current operating environment when the program starts. The initial path decision module 30 is used to determine the initial execution path with the highest matching degree with the initial hardware capability information from the execution path set based on the initial hardware capability information and the execution path description information, and configure the identifier of the initial execution path as the current execution path identifier; The runtime hardware monitoring module 40 is used to collect real-time hardware capability information of the current operating environment in response to monitoring trigger conditions during program execution. The dynamic path evaluation module 50 is used to determine the target execution path with the highest matching degree with the real-time hardware capability information from the execution path set based on the real-time hardware capability information and the execution path description information; The execution path switching control module 60 is used to compare the identifier of the target execution path with the identifier of the current execution path, and when the identifier of the target execution path is inconsistent with the identifier of the current execution path, it uses a thread synchronization mechanism to update the identifier of the current execution path to the identifier of the target execution path.

[0080] Specific limitations regarding the apparatus for dynamically switching program execution paths at runtime can be found in the foregoing limitations on the method for dynamically switching program execution paths at runtime, and will not be repeated here. Each module in the aforementioned apparatus for dynamically switching program execution paths at runtime can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0081] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: When the program starts, multiple different versions of execution paths for the same functional task are loaded to form an execution path set, and execution path description information containing hardware capability requirements is generated for each execution path in the execution path set. When the program starts, it collects the initial hardware capability information of the current operating environment; Based on the initial hardware capability information and the execution path description information, the initial execution path with the highest matching degree with the initial hardware capability information is determined from the execution path set, and the identifier of the initial execution path is configured as the current execution path identifier; During program execution, it responds to monitoring trigger conditions and collects real-time hardware capability information of the current operating environment; Based on the real-time hardware capability information and the execution path description information, the target execution path with the highest matching degree with the real-time hardware capability information is determined from the execution path set; The identifier of the target execution path is compared with the identifier of the current execution path. If the identifier of the target execution path is inconsistent with the identifier of the current execution path, the identifier of the current execution path is updated to the identifier of the target execution path using a thread synchronization mechanism.

[0082] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: When the program starts, multiple different versions of execution paths for the same functional task are loaded to form an execution path set, and execution path description information containing hardware capability requirements is generated for each execution path in the execution path set. When the program starts, it collects the initial hardware capability information of the current operating environment; Based on the initial hardware capability information and the execution path description information, the initial execution path with the highest matching degree with the initial hardware capability information is determined from the execution path set, and the identifier of the initial execution path is configured as the current execution path identifier; During program execution, it responds to monitoring trigger conditions and collects real-time hardware capability information of the current operating environment; Based on the real-time hardware capability information and the execution path description information, the target execution path with the highest matching degree with the real-time hardware capability information is determined from the execution path set; The identifier of the target execution path is compared with the identifier of the current execution path. If the identifier of the target execution path is inconsistent with the identifier of the current execution path, the identifier of the current execution path is updated to the identifier of the target execution path using a thread synchronization mechanism.

[0083] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0084] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0085] It should be noted that if any software tools or components not belonging to this company appear in the embodiments of this application, they are merely illustrative examples and do not represent actual use. The embodiments described above are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for dynamically switching program execution paths at runtime, characterized in that, Includes the following steps: When the program starts, multiple different versions of execution paths for the same functional task are loaded to form an execution path set, and execution path description information containing hardware capability requirements is generated for each execution path in the execution path set. When the program starts, it collects the initial hardware capability information of the current operating environment; Based on the initial hardware capability information and the execution path description information, the initial execution path with the highest matching degree with the initial hardware capability information is determined from the execution path set, and the identifier of the initial execution path is configured as the current execution path identifier; During program execution, it responds to monitoring trigger conditions and collects real-time hardware capability information of the current operating environment; Based on the real-time hardware capability information and the execution path description information, the target execution path with the highest matching degree with the real-time hardware capability information is determined from the execution path set; The identifier of the target execution path is compared with the identifier of the current execution path. If the identifier of the target execution path is inconsistent with the identifier of the current execution path, the identifier of the current execution path is updated to the identifier of the target execution path using a thread synchronization mechanism.

2. The method for dynamically switching program execution paths at runtime as described in claim 1, characterized in that, When the program starts, multiple different versions of execution paths for the same functional task are loaded to form an execution path set, and execution path description information containing hardware capability requirements is generated for each execution path in the execution path set, including: For the same functional task, obtain multiple different versions of execution paths that are adapted to different instruction set architectures, and determine the entry address in memory for each execution path; Define a path descriptor structure to carry execution path description information, the path descriptor structure including a function pointer field and a capability mask field for storing hardware capability requirements; For each execution path, instantiate the path descriptor structure, assign the entry address to the function pointer field, and assign the hardware capability requirements corresponding to the execution path to the capability mask field to generate execution path description information; All the generated execution path description information is stored in the global path registry to form an execution path set.

3. The method for dynamically switching program execution paths at runtime as described in claim 1, characterized in that, When the program starts, it collects initial hardware capability information of the current operating environment, including: During the initialization phase of the program startup, the processor identification instruction of the underlying processor in the current running environment is invoked; Read the value of the functional characteristic register returned after executing the processor identification instruction; The value of the function feature register is parsed, and the instruction set support flag representing the processor's extended function features is extracted from the value of the function feature register. The extracted instruction set support flags are encoded according to a preset bitmask format to generate initial hardware capability information.

4. The method for dynamically switching program execution paths at runtime as described in claim 1, characterized in that, Based on the initial hardware capability information and the execution path description information, the initial execution path with the highest matching degree with the initial hardware capability information is determined from the execution path set, and the identifier of the initial execution path is configured as the current execution path identifier, including: Obtain the preset performance priority rules for the set of execution paths; Perform a bitwise logical AND operation on the initial hardware capability information and the hardware capability requirements contained in the description information of each execution path in the execution path set to obtain a logical operation result corresponding to each execution path. Each logical operation result is compared with the hardware capability requirements in the corresponding execution path description information for numerical equality, and all execution paths with equal comparison results are identified as available execution paths that can be satisfied by the initial hardware capability information. Based on the performance priority rules, the execution path with the highest priority level is determined from all available execution paths as the initial execution path; Obtain the entry address of the initial execution path, and assign the entry address as the identifier of the initial execution path to a global pointer variable, so as to configure the global pointer variable as the identifier of the current execution path.

5. The method for dynamically switching program execution paths at runtime as described in claim 1, characterized in that, During program execution, in response to monitoring trigger conditions, real-time hardware capability information of the current operating environment is collected, including: Create and start an independently running background monitoring thread within the program process, and set the monitoring time interval; Control the background monitoring thread to enter a sleep state to pause execution; When the duration of the background monitoring thread in the sleep state reaches the monitoring time interval, the background monitoring thread is awakened, wherein the expiration of the monitoring time interval constitutes a monitoring trigger condition. By utilizing a background monitoring thread that is in an active state, hardware information reading operations are performed on the current operating environment to collect real-time hardware capability information.

6. The method for dynamically switching program execution paths at runtime as described in claim 1, characterized in that, The process involves comparing the identifier of the target execution path with the identifier of the current execution path, and updating the current execution path identifier to the identifier of the target execution path using a thread synchronization mechanism when the identifiers of the target execution path and the current execution path are inconsistent. Read the current value of the current execution path identifier, and compare the identifier of the target execution path with the current value of the current execution path identifier; If the comparison result shows that the identifier of the target execution path is inconsistent with the identifier of the current execution path, request the operating system to acquire a mutex write lock belonging to the thread synchronization mechanism to block other threads in the program from concurrently reading the identifier of the current execution path; In the state of successfully acquiring the mutex write lock, the identifier of the target execution path is assigned to the global pointer variable storing the identifier of the current execution path, so as to update the identifier of the current execution path to the identifier of the target execution path; Release the mutex write lock to unblock the concurrent read operation, so that subsequent program calls can access the target execution path through the updated current execution path identifier.

7. The method for dynamically switching program execution paths at runtime as described in claim 1, characterized in that, The process involves comparing the identifier of the target execution path with the identifier of the current execution path, and updating the current execution path identifier to the identifier of the target execution path using a thread synchronization mechanism when the identifiers of the target execution path and the current execution path are inconsistent. The process further includes: It provides a unified calling interface that encapsulates the access logic for the current execution path identifier; When a call request for the same functional task is received, a shared read lock belonging to the thread synchronization mechanism is acquired to allow multiple threads in the program to read the current execution path identifier simultaneously, but to block write operations on the current execution path identifier. If the shared read lock is successfully acquired, the current execution path identifier is read, and the execution path pointed to by the current execution path identifier is invoked to execute the same functional task; After the same functional task is completed, the shared read lock is released to allow subsequent write operations targeting the current execution path identifier.

8. A device for dynamically switching program execution paths at runtime, characterized in that, The device for dynamically switching program execution paths at runtime includes: The execution path registration module is used to load multiple different versions of execution paths for the same functional task to form an execution path set when the program starts, and to generate execution path description information containing hardware capability requirements for each execution path in the execution path set. The hardware capability acquisition module is used to acquire initial hardware capability information of the current operating environment when the program starts. The initial path decision module is used to determine the initial execution path with the highest matching degree with the initial hardware capability information from the execution path set based on the initial hardware capability information and the execution path description information, and configure the identifier of the initial execution path as the current execution path identifier; The runtime hardware monitoring module is used to collect real-time hardware capability information of the current operating environment in response to monitoring trigger conditions during program execution. The dynamic path evaluation module is used to determine the target execution path with the highest matching degree with the real-time hardware capability information from the execution path set based on the real-time hardware capability information and the execution path description information; The execution path switching control module is used to compare the identifier of the target execution path with the identifier of the current execution path, and when the identifier of the target execution path is inconsistent with the identifier of the current execution path, it uses a thread synchronization mechanism to update the identifier of the current execution path to the identifier of the target execution path.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a runtime dynamically switching program execution path program stored in the memory and executable on the processor. When the runtime dynamically switching program execution path program is executed by the processor, it implements the steps of the runtime dynamically switching program execution path method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a program for dynamically switching program execution paths at runtime. When the program for dynamically switching program execution paths at runtime is executed by the processor, it implements the steps of the method for dynamically switching program execution paths at runtime as described in any one of claims 1-7.

Images