A method for safe management of system operating parameters

Abstract

This invention provides a method for secure management of system operating parameters, specifically including: S1, modular parameter design: system operating parameters are functionally divided into independent sub-parameters, each managed by a dedicated inner class, and accessed by external modules through interface functions; S2, smart pointer memory management: std::shared_ptr is used to allocate parameter memory, and memory is automatically managed through reference counting. When parameters are updated, new memory is allocated by creating a new smart pointer, and the old parameter memory is automatically released only after the reference count reaches zero; S3, read-write lock mechanism design: read-write locks are used to allow concurrent reading by multiple threads, while exclusive locking is used for writing, balancing performance and security; and other steps. This method for secure management of system operating parameters can improve data stability, memory security, and system performance in multi-threaded environments.

Description

Technical Field

[0001] This invention relates to the technical field of monitoring equipment to ensure its sustainable and healthy operation without crashes, and specifically to a method for safe management of system operating parameters. Background Technology

[0002] System operating parameters are typically stored as global variables in a common class, allowing all business modules to read and write them directly. In multi-threaded, high-concurrency scenarios, multiple business modules may perform read and write operations simultaneously, leading to the following problems:

[0003] (1) Data inconsistency:

[0004] When business A is reading parameters, and business B happens to modify them, business A may read a partially updated value (such as a mixture of old and new values), causing a logical exception.

[0005] (2) Risks associated with memory release:

[0006] The parameter memory may be forcibly released by other services (such as when triggered by a memory reclamation mechanism), causing modules that are using that parameter to access invalid memory and leading to system crashes. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention proposes a system operation parameter security management method that can improve data stability, memory security, and system performance in multi-threaded environments.

[0008] To achieve the above technical solution, the present invention provides a method for safe management of system operating parameters, which specifically includes the following steps:

[0009] S1. Modular parameter design: The system operating parameters are divided into independent sub-parameters according to their functions. Each sub-parameter is managed by a dedicated inner class, and external modules need to access it through interface functions.

[0010] S2. Smart Pointer Memory Management: Each sub-parameter is stored in independent memory allocated by `std::shared_ptr`. When an external module uses this sub-parameter, the corresponding smart pointer's reference count is automatically incremented by 1. After use, its reference count is automatically decremented by 1. When its reference count reaches 0, the memory occupied by the sub-parameter is automatically released. An `std::shared_ptr` member variable is set in the internal management class file, referencing the smart pointer. This ensures that memory is not released even when no external module is using it. Only when the parameter is updated will this member variable re-reference the new smart pointer, and the memory occupied by the old smart pointer will be automatically released and reclaimed after no external module uses it or its reference count reaches 0. Using `std::shared_ptr` also avoids the need for external modules to create memory and copy data when using parameters; instead, all users share a single memory, saving memory overhead.

[0011] S3. Read-write lock mechanism design: Each sub-parameter is equipped with an independent read-write lock in the internal management class file. When an external module requests to use a sub-parameter, it first acquires the read lock, then gives the std::shared_ptr member variable, and then unlocks it. When an external module requests to update a sub-parameter, it first acquires the write lock, then uses std::shared_ptr to allocate new memory to store the new parameter, and lets the std::shared_ptr member variable reference this new smart pointer, and then unlocks it.

[0012] Preferably, in step S1, after the system is powered on, the system first instantiates the internal management class file. In the constructor of this internal management class file, the entire system running parameters are read from the flash. After the reading is completed, the entire system parameters are split into multiple sub-parameters according to the functional modules, and these sub-parameters are stored in the independent memory allocated by std::shared_ptr.

[0013] Preferably, in step S2, the specific process for using the parameter is as follows: when an external module requests to use the parameter, the system responds to the request, begins acquiring a read lock to ensure that the std::shared_ptr type member variable will not be changed, then releases it, and then unlocks it. Because a read lock is acquired, concurrent usage requests are supported.

[0014] Preferably, in step S2, the specific process for updating parameters is as follows: When an external module requests to update parameters, the system responds to the request and begins to acquire a write lock, ensuring that during this period, neither other external modules are allowed to request to update parameters nor to use parameters. Then, it determines whether the current parameters have changed compared to the parameters requested in this request. If no change has occurred, the system directly outputs a successful operation result. If a change has occurred, the system uses std::shared_ptr to allocate new memory space and store the new parameters. Then, the std::shared_ptr member variable of the inner class references this new smart pointer, and then the pointer is unlocked. The system then determines whether to send the new parameters to the front-end device. If so, the system sends the parameters to the front-end device and waits for a response. Then, it determines whether to write a log. If so, the system writes a log and then determines whether to write it to flash. If it determines that no log writing is required, the system directly determines whether to write it to flash. If writing to flash is required, the system writes it to flash and outputs a response result. If writing to flash is not required, the system directly outputs a successful operation result.

[0015] Preferably, in step S2, when a parameter is used, the management module acquires a read lock, then releases the smart pointer, and increments the smart pointer reference count by 1; when a parameter is updated, the management module acquires a write lock, then uses a new smart pointer to save the new parameter, and then updates the smart pointer member variable of the inner class to point to the new smart pointer, increments the new smart pointer reference count by 1, and decrements the old smart pointer reference count by 1. When the old memory reference count is 0, it is automatically released.

[0016] Preferably, in step S3, the read-write lock allows multiple read operations to be performed simultaneously, but write operations are mutually exclusive. At any given time, only one write operation or multiple read operations are allowed, but write and read operations cannot be performed simultaneously, and write operations take precedence.

[0017] Preferably, in step S3, a read lock is used in the template function get to allow multiple threads to use the get function to access the parameter simultaneously, while a write lock is used in the template function update to allow only one business function to update the parameter at a time.

[0018] The beneficial effects of the system operation parameter safety management method provided by this invention are as follows:

[0019] (1) Data stability: During the period of use, other businesses cannot modify the parameters in use.

[0020] (2) Memory safety: During the use of a parameter, other services will not release the memory used by this parameter when updating the parameter. It can only be released after no service uses it.

[0021] (3) Efficient memory reclamation: After the parameters are updated, the memory used by the old parameters that were not used will be released in a timely manner.

[0022] (4) High concurrency support: Optimize read-write lock design to improve system performance in multi-threaded environments. Attached Figure Description

[0023] Figure 1 This is a flowchart of the present invention.

[0024] Figure 2 This is a schematic diagram illustrating the operating principle of the present invention.

[0025] Figure 3 This is a flowchart of the parameter update process in this invention.

[0026] Figure 4 Code snippet of an embodiment in this invention Figure I .

[0027] Figure 5 Code snippet of an embodiment in this invention Figure II . Detailed Implementation

[0028] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art without creative effort are within the protection scope of the present invention.

[0029] Example: A method for safe management of system operating parameters.

[0030] Reference Figures 1 to 5 As shown, the present invention also provides a method for safe management of system operating parameters, which specifically includes the following steps:

[0031] (i) Modular parameter design: The system operating parameters are divided into independent sub-parameters according to their functions. Each sub-parameter is managed by a dedicated inner class, and external modules need to access it through interface functions.

[0032] In actual operation, after the system is powered on, the system first instantiates the internal management class file. In the constructor of this internal management class file, the entire system running parameters are read from flash. After the reading is completed, the entire system parameters are split into multiple sub-parameters according to the functional modules, and these sub-parameters are stored in the independent memory allocated by std::shared_ptr.

[0033] By breaking down system runtime parameters into independent sub-parameters based on their function, for example, if the entire system runtime parameters are represented by a structure `struct c`, and this structure can be divided into network parameters and GUI page parameters, then it can be further broken down into independent sub-parameters `struct a` and `struct b` (as shown below). Figure 4 and Figure 5 (See the "Simple Code Example Screenshot" example). Each sub-parameter is managed by a dedicated inner class. Managing each small parameter through inner classes achieves modular isolation of parameters, significantly reducing code complexity and enabling precise management and invocation of each sub-parameter, improving system response speed and accuracy. Furthermore, smart pointers are used to manage memory, completely preventing accidental memory release during use and enhancing system security.

[0034] (ii) Smart pointer memory management: std::shared_ptr is used to allocate parameter memory to ensure automatic reference counting. When the parameter is updated, new memory is allocated by creating a new smart pointer. The old parameter memory is automatically released only after the reference count reaches zero.

[0035] The actual process is as follows: First, each sub-parameter is stored in independent memory allocated by `std::shared_ptr`. When an external module uses this sub-parameter, the reference count of the corresponding smart pointer is automatically incremented by 1, and after use, its reference count is automatically decremented by 1. When its reference count reaches 0, the memory occupied by the sub-parameter is automatically released. Then, a member variable of type `std::shared_ptr` is set in the internal management class file, referencing the smart pointer. This ensures that the memory is not released even when no external module is using it; only when the parameter is updated will this member variable re-reference the new smart pointer. The memory occupied by the old smart pointer is automatically released and reclaimed after no external module uses it or when its reference count reaches 0. Using `std::shared_ptr` also avoids the need for external modules to create memory and copy data when using parameters; instead, all users share a single memory, saving memory overhead.

[0036] When an external module requests to use a parameter, the system responds by acquiring a read lock to ensure that the `std::shared_ptr` member variable is not modified, then releasing the parameter, incrementing the reference count by 1, and finally unlocking the lock. After the external module finishes using the parameter, i.e., after the smart pointer's scope ends, the reference count is decremented by 1. Because it uses a read lock, concurrent requests are supported.

[0037] When an external module requests to update parameters, the system responds by acquiring a write lock to ensure that no other external module is allowed to update or use the parameters during this period. It then checks if the current parameters have changed from those requested. If not, it directly outputs a success result. If they have changed, it allocates new memory space using `std::shared_ptr` to store the new parameters, sets a member variable of type `std::shared_ptr` in the inner class to reference this new smart pointer, unlocks it, and then determines whether to send the new parameters to the front-end device. If so, it sends them and waits for a response. Next, it checks if logging is required; if so, it writes the log and then checks if writing to flash is necessary. If logging is not required, it directly checks if writing to flash is necessary; if writing to flash is required, it writes to flash and outputs a response. If writing to flash is not necessary, it directly outputs a success result.

[0038] When parameters are used, the management module acquires a read lock, then releases the smart pointer, increments the smart pointer's reference count by 1, and then unlocks it. When parameters are updated, the management module acquires a write lock, uses a new smart pointer to store the new parameters, then updates the inner class's smart pointer member variable to point to the new smart pointer, increments the new smart pointer's reference count by 1, decrements the old smart pointer's reference count by 1, and then unlocks it. When the old memory reference count reaches 0, the memory is automatically released.

[0039] During the parameter's usage, updates from other business processes will not release the memory used by that parameter. The memory will only be released after no business processes have used it, significantly improving memory security. Furthermore, because updated parameters are stored in memory created using new smart pointers, the integrity of older parameters is not affected, further ensuring data integrity. Moreover, recreating new smart pointers to store new parameters completely prevents accidental memory release during use, achieving zero crash risk.

[0040] In specific implementation, such as Figure 4 and Figure 5As shown, the system runtime parameter memory is allocated using `std::shared_ptr` provided by the C++11 standard library. `std::shared_ptr` internally maintains a counter for the number of times it is currently held. Each time it is held (i.e., assigned to another variable), this counter increments by 1, and when it is released (i.e., the previously assigned variable is destroyed), the counter decrements by 1. After decrementing, the counter is checked for zero; if it is zero, the memory it occupies is automatically released. During the assignment process using smart pointers, no new memory is allocated or data is copied; all users share the same memory space, only the counter changes. After the system powers on, it immediately reads the `struct c` from the flash memory where system parameters are stored, and then creates two sub-parameters corresponding to `std::shared_ptr`. s1 and std::shared_ptr `s2` contains two smart pointers. During system operation, if a business function needs to use `struct a`, it will call the template function `get` to return `std::shared_ptr`. Smart pointers in s1, such as std::shared_ptr<const a> s3 = get When s1 is destroyed, its reference count is incremented by 1, for example, from 1 to 2. When s3 is destroyed, s1's reference count is decremented by 1, for example, from 2 to 1. When the reference count reaches 0, the memory it occupies will be released. If a business function needs to update struct a, it will update the content of s1 by calling the template function update. For example, updating the content of s3 to s1 is called update. (s3) In the update function, the operation s1 = s3 is executed, which assigns the smart pointer of the variable s1 to the smart pointer of s3. The reference count of the smart pointer previously stored in s1 is reduced by one due to the change of s1, that is, the reference count of the previously stored smart pointer is reduced by 1. If there are other business operations that still hold the previously stored smart pointer, its reference count will still be non-zero, that is, the previous memory will not be released. In this way, the business using it will not crash due to accessing the released memory, nor will it cause an exception due to the modification of part of the structure content.

[0041] (III) Read-Write Lock Mechanism Design: Each sub-parameter is equipped with an independent read-write lock in the internal management class file. When an external module requests to use a sub-parameter, it first acquires the read lock, then releases the `std::shared_ptr` member variable, and then unlocks it. When an external module requests to update a sub-parameter, it first acquires the write lock, then uses `std::shared_ptr` to allocate new memory to store the new parameter, and lets the `std::shared_ptr` member variable reference this new smart pointer, and then unlocks it. This read-write lock mechanism allows for concurrent reading by multiple threads, while providing exclusive locking during writing, balancing performance and security.

[0042] Read-write locks allow multiple read operations to occur concurrently, but write operations are mutually exclusive. That is, only one write operation or multiple read operations are allowed at any given time, but not both simultaneously, and write operations take precedence. Using a read lock in the template function `get` allows multiple threads to use the `get` function to access the parameter simultaneously. Conversely, using a write lock in the template function `update` allows only one business logic update to be performed on the parameter at a time.

[0043] By optimizing the read-write lock mechanism and adopting a concurrency control method for thread-safe access, we can enable thread-safe access, improve system throughput, and enhance system performance in a multi-threaded environment.

[0044] The system's parameter security management method can effectively improve data stability, memory security, and system performance in multi-threaded environments.

[0045] The above description is only a preferred embodiment of the present invention, but the present invention should not be limited to the content disclosed in the embodiments and drawings. Therefore, any equivalent or modified embodiments made without departing from the spirit of the present invention shall fall within the protection scope of the present invention.

Claims

1. A method for safe management of system operating parameters, characterized in that... Specifically, the steps include the following: S1. Modular parameter design: The system operating parameters are divided into independent sub-parameters according to their functions. Each sub-parameter is managed by a dedicated inner class, and external modules need to access it through interface functions. When the system is powered on, the system first instantiates the internal management class file. In the constructor of this internal management class file, the entire system operating parameters are read from flash. After the reading is completed, the entire system parameters are divided into multiple sub-parameters according to the functional modules, and these sub-parameters are stored in independent memory allocated by std::shared_ptr. S2. Smart Pointer Memory Management: Each sub-parameter is stored in independent memory allocated by std::shared_ptr. When an external module uses this sub-parameter, the reference count of the corresponding smart pointer is automatically incremented by 1. After use, its reference count is automatically decremented by 1. When its reference count reaches 0, the memory occupied by the sub-parameter is automatically released. A member variable of type std::shared_ptr is set in the internal management class file and references the smart pointer to ensure that the memory is not released even when no external module uses it. Only when the parameter is updated will this member variable re-reference the new smart pointer, and the memory occupied by the old smart pointer will be automatically released and reclaimed after no external module uses it or its reference count reaches 0. S3. Read-write lock mechanism design: Each sub-parameter is equipped with an independent read-write lock in the internal management class file. When an external module requests to use a sub-parameter, it first acquires the read lock, then gives the std::shared_ptr member variable, and then unlocks it. When an external module requests to update a sub-parameter, it first acquires the write lock, then uses std::shared_ptr to allocate new memory to store the new parameter, and lets the std::shared_ptr member variable reference this new smart pointer, and then unlocks it.

2. The system operation parameter safety management method as described in claim 1, characterized in that, In step S2, the specific process for using parameters is as follows: when an external module requests to use parameters, the system responds to the request, begins to acquire a read lock to ensure that the member variable of type std::shared_ptr will not be changed, then gives it out, and then unlocks it.

3. The system operation parameter safety management method as described in claim 2, characterized in that, In step S2, the specific process for updating parameters is as follows: When an external module requests to update parameters, the system responds to the request and begins to acquire a write lock to ensure that during this period, neither other external modules are allowed to request to update parameters nor to use parameters. Then, it determines whether the current parameters have changed compared to the parameters requested in this request. If no change has occurred, the system directly outputs a successful operation result. If a change has occurred, the system allocates new memory space using std::shared_ptr and stores the new parameters. Then, it makes the std::shared_ptr member variable of the inner class reference this new smart pointer, unlocks it, and then determines whether to send the new parameters to the front-end device. If so, it sends them to the front-end device and waits for a response. Then, it determines whether to write a log. If so, it writes a log and then determines whether to write it to flash. If it is determined that writing to the log is not required, then directly determine whether writing to the flash is required; if writing to the flash is required, then write to the flash and provide a response; if writing to the flash is not required, then directly provide a successful operation result.

4. The system operating parameter safety management method as described in claim 2, characterized in that, In step S2, when a parameter is used, the management module acquires a read lock and then releases the smart pointer, incrementing the smart pointer reference count by 1. When a parameter is updated, the management module acquires a write lock and then uses a new smart pointer to save the new parameter. Then, the smart pointer member variable of the inner class is updated to point to the new smart pointer, incrementing the new smart pointer reference count by 1 and decrementing the old smart pointer reference count by 1. When the old memory reference count is 0, it is automatically released.

5. The system operating parameter security management method as described in claim 1, characterized in that, In step S3, the read-write lock allows multiple read operations to be performed simultaneously, but write operations are mutually exclusive. At any given time, only one write operation or multiple read operations are allowed, but write and read operations cannot be performed simultaneously, and write operations take precedence.

6. The system operating parameter security management method as described in claim 1, characterized in that, In step S3, a read lock is used in the template function get to allow multiple threads to use the get function to access the parameters simultaneously, while a write lock is used in the template function update to allow only one business update of the parameters at a time.

Images