A method for protecting high-frequency critical resources in embedded real-time operating system device management

Abstract

This invention belongs to the field of computer system software technology, specifically relating to a method for protecting high-frequency critical resources in embedded real-time operating system device management. It improves the efficiency of concurrent execution of multi-core programs in high-frequency critical sections of device management when acquiring file descriptor driver information, reduces the proportion of programs that cannot be executed concurrently in critical sections, and enhances the concurrent execution capability of multi-core programs in high-frequency critical sections of device management while ensuring the multi-core determinism of programs. This brings a significant performance improvement to operating system device management.

Description

Technical Field

[0001] This invention belongs to the field of computer system software technology, specifically relating to a method for protecting high-frequency critical resources in embedded real-time operating system device management. Background Technology

[0002] The most widely used technique in multi-core concurrent programming is lock-based implementation. The existence of locks implies lock contention, and this contention intensifies as the critical section accessed by multiple cores becomes more complex. Locking methods can be chosen from spinlocks or mutexes. The main difference between spinlocks and mutexes is that spinlocks do not cause sleeping or rescheduling, while mutexes may cause sleeping and rescheduling. Therefore, for critical sections with relatively short protection times, deterministic spinlocks are more suitable.

[0003] Traditional methods use deterministic spinlocks to protect critical sections. Entering and exiting the critical section requires acquiring and releasing deterministic spinlock resources. However, the acquisition and release of deterministic spinlocks consumes a lot of time in high-frequency areas and also turns multi-core concurrent execution into serial processing. Summary of the Invention

[0004] In view of this, the present invention provides a method for protecting high-frequency critical resources in embedded real-time operating system device management, which improves the efficiency of concurrent execution of multi-core programs in high-frequency critical sections of device management that obtain file descriptor driver information, reduces the proportion of programs that cannot be executed concurrently in critical sections, and improves the concurrent execution capability of multi-core programs in high-frequency critical sections of device management while ensuring the multi-core determinism of programs, thus bringing a significant performance improvement to operating system device management.

[0005] To achieve the above-mentioned technical objectives, the specific technical solution adopted by the present invention is as follows:

[0006] A method for protecting high-frequency critical resources in embedded real-time operating system device management includes the following steps:

[0007] Step 1): During the initialization of the operating system, a fixed space is allocated to the device driver information resources and file descriptor resources for device management operations based on the maximum number of drivers and the maximum number of file descriptors configured in the operating system configuration.

[0008] Step 2): When the user calls the operating system device management interface, they enter a high-frequency critical section; atomic operations are used to obtain the driver information in the specified file descriptor, and the driver information in the file descriptor is used as the flag information.

[0009] Step 3), call the memory read fence interface;

[0010] Step 4) Use atomic operations to obtain internal value information from the specified file descriptor;

[0011] Step 5), call the memory read fence interface again;

[0012] Step 6): Perform another atomic operation to obtain the driver information in the file descriptor and compare it with the flag information obtained in Step 2). If they do not match, jump to Step 2); if they match, jump to Step 7.

[0013] Step 7) Determine whether the obtained file descriptor driver information is valid. If it is invalid, set an error number and return an error. If it is valid, use atomic operations to retrieve the interface driver function that needs to be used.

[0014] Furthermore, in steps 2), 4), and 6), the static space of the specified file descriptor comes from the fixed space allocated for the file descriptor resources in step 1).

[0015] During operating system operation, the device management module is used for:

[0016] Ensures that the spatial location of the specified file descriptor remains unchanged during operations on free and used file descriptors.

[0017] Furthermore, in steps 2), 6), and 7), the static space of the specified file descriptor comes from the fixed space allocated by the device driver information resource in step 1).

[0018] During the operation of the operating system, the device management module is also used for:

[0019] Ensure that the spatial location of the specified driver information remains unchanged during the operation of idle and used driver information.

[0020] Furthermore, in step 3), the memory read barrier is invoked to ensure the execution order of steps 2)-4).

[0021] Furthermore, in step 5), the memory read barrier is invoked again to ensure the execution order of steps 4)-6).

[0022] Furthermore, in step 6), checking the correctness of the file descriptor driver information is used for:

[0023] Determine whether the driver information recorded in the file descriptor has been changed by the operation of a task running on another processor core of the operating system in steps 3)-6). Attached Figure Description

[0024] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0025] Figure 1 This is a schematic diagram of the high-frequency critical section optimization process of a high-frequency critical resource protection method for embedded real-time operating system device management in a specific embodiment of the present invention. Detailed Implementation

[0026] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0027] The following specific examples illustrate the implementation of this disclosure. Those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific embodiments, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0028] It should be noted that various aspects of embodiments within the scope of the appended claims are described below. It will be apparent that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Additionally, this device and / or method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0029] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The drawings only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0030] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0031] In one embodiment of the present invention, a method for protecting high-frequency critical resources in embedded real-time operating system device management includes the following steps:

[0032] Step 1): During the initialization of the operating system, a fixed space is allocated to the device driver information resources and file descriptor resources for device management operations based on the maximum number of drivers and the maximum number of file descriptors configured in the operating system configuration.

[0033] Step 2): When the user calls the operating system device management interface, they enter a high-frequency critical section; atomic operations are used to obtain the driver information in the specified file descriptor, and the driver information in the file descriptor is used as the flag information.

[0034] Step 3), call the memory read fence interface;

[0035] Step 4) Use atomic operations to obtain internal value information from the specified file descriptor;

[0036] Step 5), call the memory read fence interface again;

[0037] Step 6): Perform another atomic operation to obtain the driver information in the file descriptor and compare it with the flag information obtained in Step 2). If they do not match, jump to Step 2); if they match, jump to Step 7.

[0038] Step 7) Determine whether the obtained file descriptor driver information is valid. If it is invalid, set an error number and return an error. If it is valid, use atomic operations to retrieve the interface driver function that needs to be used.

[0039] In this embodiment, in steps 2), 4), and 6), the static space of the specified file descriptor comes from the fixed space allocated for file descriptor resources in step 1).

[0040] During operating system operation, the device management module is used for:

[0041] Ensures that the spatial location of the specified file descriptor remains unchanged during operations on free and used file descriptors.

[0042] In this embodiment, in steps 2), 6), and 7), the static space of the specified file descriptor comes from the fixed space allocated by the device driver information resource in step 1).

[0043] During the operation of the operating system, the device management module is also used for:

[0044] Ensure that the spatial location of the specified driver information remains unchanged during the operation of idle and used driver information.

[0045] In this embodiment, in step 3), the memory read barrier is invoked to ensure the execution order of steps 2)-4).

[0046] In this embodiment, in step 5), the memory read barrier is invoked again to ensure the execution order of steps 4)-6).

[0047] In this embodiment, step 6) involves checking the correctness of the file descriptor driver information for the following purposes:

[0048] Determine whether the driver information recorded in the file descriptor has been changed by the operation of a task running on another processor core of the operating system in steps 3)-6).

[0049] In multi-core concurrent programming, atomic operations are the ideal choice because they are implemented using processor hardware-level assembly instructions, resulting in optimal program execution efficiency. However, the scope of protection for atomic operations is generally limited to specific 32-bit or 64-bit data. If atomic operation combination optimization can be used, it is possible to achieve fine-grained protection of critical sections in multi-core systems, improving concurrent execution efficiency. This requires fine-grained partitioning of resources in the critical section and special structural design to achieve protection in specific scenarios.

[0050] For the simultaneous protection of multiple critical resources across the entire device management module, the approach has shifted from simple coarse-grained protection using a single large lock to improving the performance of high-frequency critical sections through fine-grained division and optimized design. Low-frequency access resources are protected using coarser-grained locks, while high-frequency critical sections utilize special concurrency optimization designs to enhance execution efficiency.

[0051] Therefore, the design approach for optimizing concurrent access in multi-core device management is to identify high-frequency critical sections by fine-grained partitioning of critical resources in the multi-core device management structure, and then optimize the concurrent execution of code within these high-frequency critical sections. High-frequency access code is prioritized for optimization. A coarse-grained lock protection method is used to protect other critical resources in device management, as these resources are used infrequently, only during driver and device initialization. Traditional large locks are used for critical section resource protection. For multi-core resources related to obtaining file descriptor driver information that are frequently accessed by users when using device management via standard I / O interfaces, a special concurrency optimization method designed in this project is employed for protection.

[0052] In one embodiment of the present invention, a method for protecting high-frequency critical resources in embedded real-time operating system device management is proposed, comprising the following steps:

[0053] Step 1): During operating system initialization, a fixed space is allocated to the device driver information resources and file descriptor resources for device management operations based on the maximum number of drivers and the maximum number of file descriptors configured in the operating system configuration.

[0054] Step 2): When the user calls the operating system device management interface, they enter a high-frequency critical section; atomic operations are used to obtain the driver information in the specified file descriptor, and the driver information in the file descriptor is used as the flag information.

[0055] Step 3), call the memory read fence interface;

[0056] Step 4) Use atomic operations to obtain internal value information from the specified file descriptor;

[0057] Step 5), call the memory read fence interface again;

[0058] Step 6): Perform another atomic operation to obtain the driver information in the file descriptor and compare it with the flag information obtained in Step 2). If they do not match, jump to Step 2); if they match, jump to Step 7.

[0059] Step 7) Determine whether the obtained file descriptor driver information is valid. If it is invalid, set an error number and return an error. If it is valid, use atomic operations to retrieve the interface driver function that needs to be used.

[0060] In this embodiment, in steps 2), 4), and 6), the static space of the specified file descriptor comes from the fixed space allocated for the file descriptor resources in step 1).

[0061] During operating system operation, the device management module is used for:

[0062] Ensures that the spatial location of the specified file descriptor remains unchanged during operations on free and used file descriptors.

[0063] In this embodiment, in steps 2), 6), and 7), the static space of the specified file descriptor comes from the fixed space allocated by the device driver information resource in step 1).

[0064] During the operation of the operating system, the device management module is also used for:

[0065] Ensure that the spatial location of the specified driver information remains unchanged during the operation of idle and used driver information.

[0066] In this embodiment, in step 3), the memory read barrier is invoked to ensure the execution order of steps 2)-4).

[0067] In this embodiment, in step 5), the memory read barrier is invoked again to ensure the execution order of steps 4)-6).

[0068] In this embodiment, step 6) checks the correctness of the file descriptor driver information for the following purposes:

[0069] Determine whether the driver information recorded in the file descriptor has been changed by operations of tasks running on other processor cores of the operating system in steps 3)-6).

[0070] Further explanation:

[0071] (1) Device-driven information resources: During program execution, the location and size of the storage space do not change, providing structural invariance guarantee for obtaining the flag bits of atomic operation combinations in optimization.

[0072] (2) When a user calls the operating system device management interface, a high-frequency critical section will be entered; atomic operations are used to obtain the driver information in the specified file descriptor; the driver information in the file descriptor is used as the flag information;

[0073] (3) Call the memory read fence interface.

[0074] It should be noted that the implementation of memory read barriers differs across different processor architectures; this is a general term for this function.

[0075] The memory read barrier is used to prevent out-of-order execution by the processor during program execution, which could cause premature reading when the driver information may have changed later. Out-of-order execution may result in (4) being executed first, and then another core having changed the information that (2) was going to obtain, and then executing (2). At this time, the driver information in the file descriptor obtained by (2) and the internal value information in the file descriptor obtained by (4) are no longer matched.

[0076] (4) Atomic operations retrieve internal value information from a specified file descriptor;

[0077] (5) Call the memory read fence interface;

[0078] It should be noted that the implementation of memory read barriers differs across different processor architectures; this is a general term for this function.

[0079] The memory read barrier is used to prevent out-of-order execution by the processor during program execution, which could cause premature reading when it is necessary to confirm that the driver information may have changed. Out-of-order execution may result in (6) being executed first, and then another core modifying the information obtained by (4). If the driver information in the file descriptor obtained by (2) is still equal to the information obtained by (6), then the driver information in the file descriptor obtained by (2) and the internal value information in the file descriptor obtained by (4) are no longer matched.

[0080] (6) Re-atomize the drive information in the file descriptor obtained by the atomic operation and compare it with the drive information (flag information) in the file descriptor obtained by (2) to see if it has been changed to determine whether it has been changed by another kernel. If it has been changed, repeat the process of (2).

[0081] The purpose of checking the correctness of the file descriptor driver information is that when multiple cores access the system, the driver information recorded in the specified file descriptor may be changed by other cores during the process from (3) to (5). Therefore, it is necessary to re-check the driver information (flag information) in this file descriptor. If it has been changed, the process needs to be re-acquired.

[0082] (7) Determine whether the obtained file descriptor driver information is valid. If it is invalid, set an error number and return an error. If it is correct, use atomic operations to retrieve the interface driver function to be used for device management and subsequent operations.

[0083] To further explain, the embedded real-time operating system device management high-frequency critical resource protection method of this embodiment includes the following steps:

[0084] Step 101: First, the operating system has the ability to configure device resources, which can be done through header file configuration record tables, etc. During initialization, the device driver information resources and file descriptor resources of the device management operation are allocated a fixed size according to the maximum number of drivers and file descriptors configured in the operating system. After initialization, during program operation, the storage space of device driver information resources and file descriptor resources in device management is not released or changed, and the position and size of resources in the device driver information resource pool and file descriptor resource pool do not change.

[0085] Step 102: After the user installs the device driver and adds the user device, different tasks on different processor cores call the standard I / O access interface of the operating system to open the device and obtain a valid file descriptor. After that, different tasks on different processor cores will enter the high-frequency critical section when calling different I / O access interfaces.

[0086] It should be noted that the interfaces for calling IO access include read interfaces, write interfaces, and control interfaces.

[0087] Steps 103 to 108 constitute the processing flow for the high-frequency critical section of accessing device management and obtaining file descriptor driver information, as follows: Figure 1 As shown, steps 103 to 108 belong to the concurrent critical section, which includes multiple threads on multiple processor cores accessing it simultaneously.

[0088] Step 103: In the multi-task call to the operating system device management interface on the user's multi-core, a high-frequency critical section will be entered. First, atomic operations are performed to obtain the driver information in the specified file descriptor, and the driver information in the file descriptor is used as the flag information.

[0089] Step 104: Call the encapsulated memory read barrier interface provided by the operating system. It should be noted that the implementation of the memory read barrier is different in different processor architectures. Here, we are referring to this function as a general operation.

[0090] Step 105: Atomic operations are used to obtain internal value information from a specified file descriptor;

[0091] Step 106: Call the encapsulated memory read barrier interface provided by the operating system. It should be noted that the implementation of the memory read barrier is different in different processor architectures. Here, we are referring to this function as a general operation.

[0092] Step 107: Compare the driver information obtained from the file descriptor by the atomic operation with the driver information (flag information) obtained from the file descriptor in step 103 to see if it has been changed to determine if it has been changed by another kernel. If it has been changed, repeat step 103.

[0093] Step 108: Determine whether the file descriptor driver information obtained this time is valid. If it is invalid, set an error number and return an error. If it is correct, use atomic operations to retrieve the interface driver function that needs to be used and then perform the next operation of device management.

[0094] The above description is merely a specific embodiment of this disclosure, but the scope of protection of this disclosure is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this disclosure should be included within the scope of protection of this disclosure. Therefore, the scope of protection of this disclosure should be determined by the scope of the claims.

Claims

1. A method for protecting high-frequency critical resources in embedded real-time operating system device management, characterized in that, Includes the following steps: Step 1) During the initialization of the operating system, a fixed space is allocated to the device driver information resources and file descriptor resources for device management operations according to the configuration of the maximum number of drivers and the maximum number of file descriptors in the operating system configuration. Step 2), when the user calls the operating system device management interface, the user enters a high-frequency critical section; atomic operations are used to obtain the driver information in the specified file descriptor and use the driver information in the file descriptor as the flag information; Step 3), call the memory read fence interface; Step 4), atomic operations to obtain internal value information from the specified file descriptor; Step 5), call the memory read fence interface again; Step 6): Perform another atomic operation to obtain the driver information in the specified file descriptor and compare it with the flag information obtained in Step 2). If they do not match, proceed to Step 2); if they match, proceed to Step 7). Step 7) Determine whether the obtained specified file descriptor driver information is valid. If invalid, set an error number and return an error. If valid, use atomic operations to retrieve the required interface driver function.

2. The method for protecting high-frequency critical resources in embedded real-time operating system device management according to claim 1, characterized in that, In steps 2), 4), and 6), the static space of the specified file descriptor comes from the fixed space allocated for the file descriptor resources in step 1); During operating system operation, the device management module is used for: Ensures that the spatial location of the specified file descriptor remains unchanged during operations on free and used file descriptors.

3. The method for protecting high-frequency critical resources in embedded real-time operating system device management according to claim 2, characterized in that, In steps 2), 6), and 7), the static space of the specified file descriptor comes from the fixed space allocated by the device driver information resource in step 1); During the operation of the operating system, the device management module is also used for: Ensure that the spatial location of the specified driver information remains unchanged during the operation of idle and used driver information.

4. The method for protecting high-frequency critical resources in embedded real-time operating system device management according to claim 1, characterized in that, In step 6), checking the correctness of the specified file descriptor driver information is used for: Determine whether the driver information recorded in the specified file descriptor was changed by the operation of a task running on another processor core of the operating system in steps 3)-6).

Images