Method and device for executing operation request of resource, equipment, medium and product

Abstract

The invention discloses a resource operation request execution method and device, equipment, a medium and a product. In response to an operation request of the resource, information of a descriptor state and information of a lock state in a resource descriptor corresponding to the resource are obtained; verifying the legality of the operation request through atomic operation according to the information of the descriptor state and the information of the lock state to obtain a first verification result; and under the condition that the first verification result is successful verification, executing the operation request on the resource. According to the embodiment of the invention, the requests can be quickly and accurately processed on the premise of ensuring data consistency and operation legality, and the concurrent processing capability of the system is improved.

Description

Technical Field

[0001] This application belongs to the field of communication technology, and in particular relates to a method, apparatus, device, medium and product for executing operation requests for resources. Background Technology

[0002] In related technologies, multiple threads or processes often simultaneously initiate operation requests to shared resources, such as reading and writing operations. While this multi-threaded or multi-process architecture brings high-efficiency processing capabilities, it also raises serious challenges in concurrent operations: multiple threads often simultaneously initiate operation requests to shared resources such as database data and file system files, which can easily lead to chaos.

[0003] Based on this, some related technologies use locking mechanisms to solve the problem of multi-threaded concurrent operations. Although they can ensure that only one thread accesses the shared resources at the same time, they are prone to deadlock and livelock and become a performance bottleneck under high concurrency. Summary of the Invention

[0004] This application provides a method, apparatus, device, medium, and product for executing resource operation requests, which can quickly and accurately process these requests while ensuring data consistency and operational legality, thereby improving the system's concurrent processing capabilities.

[0005] In a first aspect, embodiments of this application provide a method for executing a resource operation request, comprising: In response to a resource operation request, obtain information about the descriptor status and lock status from the resource descriptor corresponding to the resource; Through atomic operations, the legality of the operation request is verified based on the information of the descriptor state and the lock state, and a first verification result is obtained; if the first verification result is successful, the operation request is executed on the resource.

[0006] Based on the same inventive concept, in a second aspect, embodiments of this application also provide an execution device for a resource operation request, comprising: The acquisition module is used to respond to resource operation requests and obtain information about the descriptor status and lock status in the resource descriptor corresponding to the resource. The execution module is used to verify the legality of the operation request through atomic operations, based on the information of the descriptor state and the lock state, and obtain the first verification result; if the first verification result is successful, the operation request is executed on the resource.

[0007] Based on the same inventive concept, in a third aspect, embodiments of this application also provide an execution device for a resource operation request, the device including a processor and a memory storing computer program instructions; when the processor executes the computer program instructions, it implements the first aspect, or the method for executing a resource operation request in any embodiment of the first aspect.

[0008] Based on the same inventive concept, in a fourth aspect, embodiments of this application also provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement the execution method of the resource operation request in the first aspect or any embodiment of the first aspect.

[0009] Based on the same inventive concept, in a fifth aspect, embodiments of this application also provide a computer program product, wherein when the instructions in the computer program product are executed by the processor of a device, the device is able to execute the execution method of the resource operation request in the first aspect or any embodiment of the first aspect.

[0010] The resource operation request execution method, apparatus, device, medium, and product provided in this application embodiment obtain, upon receiving a resource operation request, information about the descriptor state and lock state in the resource descriptor corresponding to the resource, and then perform an atomic operation: verifying the legality of the operation request based on the descriptor state and lock state information, and executing the operation request on the resource if the verification is successful. This atomic operation is not interrupted by other threads or processes during execution; it either executes completely successfully or not at all, without any intermediate states. This application embodiment integrates key information (such as descriptor state and lock state information) into a single resource descriptor, ensuring data consistency. Furthermore, by integrating the verification and resource operation steps into an inseparable whole through atomic operations, it can quickly and accurately process these requests while ensuring data consistency and operation legality, thus improving the system's concurrent processing capabilities. Attached Figure Description

[0011] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings, in which the same or similar reference numerals denote the same or similar features, and the drawings are not drawn to scale.

[0012] Figure 1 This is a flowchart illustrating a method for executing a resource operation request provided in an embodiment of this application; Figure 2 This is another flowchart illustrating the method for executing operation requests for resources provided in this application embodiment; Figure 3This is another flowchart illustrating the method for executing operation requests for resources provided in this application embodiment; Figure 4 This is another flowchart illustrating the method for executing operation requests for resources provided in this application embodiment; Figure 5 This is another flowchart illustrating the method for executing operation requests for resources provided in this application embodiment; Figure 6 This is another flowchart illustrating the method for executing operation requests for resources provided in this application embodiment; Figure 7 This is another flowchart illustrating the method for executing operation requests for resources provided in this application embodiment; Figure 8 This application provides a schematic diagram illustrating the changes in the status field of the resource descriptor in the method for executing operation requests for resources. Figure 9 This application provides a schematic diagram of the operating system architecture in the method for executing resource operation requests. Figure 10 This is a schematic diagram of a structure of an execution device for a resource operation request provided in an embodiment of this application; Figure 11 This is a schematic diagram of a device for executing operation requests for resources provided in an embodiment of this application. Detailed Implementation

[0013] The features and exemplary embodiments of various aspects of this application will now be described in detail. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only configured to explain this application and are not configured to limit this application. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples of this application.

[0014] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0015] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0016] Various modifications and variations can be made to this application without departing from its spirit or scope, which will be apparent to those skilled in the art. Therefore, this application is intended to cover modifications and variations falling within the scope of the corresponding claims (the claimed technical solutions) and their equivalents. It should be noted that the implementation methods provided in the embodiments of this application can be combined with each other without contradiction.

[0017] Before describing the technical solutions provided in the embodiments of this application, in order to facilitate understanding of the embodiments of this application, this application first specifically explains the problems existing in the related technologies: In related technologies, multiple threads or processes often simultaneously initiate operation requests to shared resources, such as reading and writing operations. While this multi-threaded or multi-process architecture brings high-efficiency processing capabilities, it also raises serious challenges in concurrent operations: multiple threads often simultaneously initiate operation requests to shared resources such as database data and file system files, which can easily lead to chaos.

[0018] Some related technologies use locking mechanisms to solve the problem of multi-threaded concurrent operations. Although they can ensure that only one thread accesses the shared resources at a time, they are prone to deadlock and livelock and become a performance bottleneck under high concurrency.

[0019] Taking a file system as an example, the main framework of a file system is the Virtual File System (VFS) layer, and the underlying physical files such as fatfs, ext4, and littlefs. VFS provides an abstraction layer that separates the POSIX application programming interface (API) from the specific interface implementations of different storage devices, making the underlying file system type and device type transparent to upper-layer applications. VFS provides an abstract struct structure, and each specific file system needs to fill in its own fields and functions. When upper-layer applications perform read and write operations, VFS can perform different actual operations based on which "actual file system" (which partition) you are operating on.

[0020] When upper-layer applications concurrently perform operations on a partition, the Virtual File System (VFS) layer needs to effectively manage and protect concurrent file access. To ensure data consistency and integrity, the VFS layer typically employs various locking mechanisms to coordinate access to the same resource by multiple threads or processes. Common mechanisms include spin locks, mutexes, and read-write locks.

[0021] Spin locks are a lightweight locking mechanism suitable for situations where the lock is held for a very short time. When a thread attempts to acquire a spin lock, if the lock is already held by another thread, the thread will continuously spin (cyclically checking the lock's state) until the lock is released.

[0022] A mutex is a commonly used locking mechanism to ensure that only one thread can access a shared resource at a time. When a thread acquires a mutex, other threads attempting to acquire the lock will be blocked (enter a sleep state) until the lock is released.

[0023] Read-write locks allow multiple read threads to access a shared resource simultaneously, but require exclusive access to the resource during write operations. Read-write locks achieve this by maintaining a reader counter and a writer lock state.

[0024] Related techniques are commonly found in lock optimization, such as using multi-level locks to distribute concurrency or using machine learning models to optimize lock scheduling mechanisms.

[0025] In the Virtual File System (VFS), concurrent file access and resource protection face numerous challenges, especially in high-concurrency environments and RTOS / embedded scenarios. Existing locking mechanisms have significant limitations in performance and resource utilization efficiency, and lack effective mechanisms for observing and locating system problems. Specifically, the following are the main limitations of current locking mechanisms and the shortcomings of system monitoring: 1. Concurrency issues unique to the VFS layer.

[0026] 1) Concurrency limitations of multiple underlying file systems.

[0027] The VFS layer manages multiple underlying physical file systems (such as fatfs, ext4, littlefs, etc.), which may correspond to different hardware storage devices. Current technology uses mutex locks to protect VFS layer operations, meaning that even though different underlying file systems correspond to different hardware devices, true concurrent operations cannot be achieved. This design severely limits the utilization of hardware concurrency capabilities, creating a significant performance bottleneck in storage-intensive applications.

[0028] 2) Resource descriptor lifecycle management issues.

[0029] The lifecycle management of resource descriptors, including allocation, initialization, use, and release, requires precise state control. Related locking mechanisms cannot accurately distinguish between different stages of file operations (such as open in progress, open completed, read / write in progress, close in progress, etc.), leading to race conditions during file operation state transitions and causing problems such as resource descriptor leaks or duplicate releases.

[0030] 3) Performance issues in RTOS / embedded environments.

[0031] In resource-constrained RTOS / embedded environments, CPU and memory resources are extremely precious. The context switching overhead caused by existing locking mechanisms has a particularly severe impact in these environments. Frequent thread blocking and waking not only consume a significant amount of CPU time but also affect the system's real-time responsiveness.

[0032] 2. Specific defects of existing locking mechanisms.

[0033] 1) The CPU idling problem of spinlock.

[0034] Spin locks continuously consume CPU resources while attempting to acquire the lock, constantly spinning. When a thread fails to acquire the lock within a short time, this continuous spinning leads to wasted CPU resources. In high-concurrency environments, multiple threads spinning simultaneously can cause significant CPU idle time, thus significantly degrading overall system performance. This mechanism is suitable for situations where the lock holding time is extremely short, but in long-term locking operations, the effect of spin locks is counterproductive.

[0035] 2) Blocking problem of mutex locks.

[0036] A mutex (mutex) allows only one thread to exclusively access a shared resource during concurrent access. This is particularly inefficient in high-concurrency read scenarios because each read operation must wait for the previous thread to release the lock. When a thread fails to acquire the mutex, it enters a blocked state (sleep) until the lock is released and it is awakened. This context switching incurs additional overhead, and frequent thread switching, especially in high-concurrency environments, can severely impact system response time and performance.

[0037] 3) The complexity and overhead of read-write locks.

[0038] While read-write locks allow multiple read threads to access resources concurrently, their implementation requires maintaining complex counters and state management. This mechanism increases code complexity and maintenance costs, and also introduces potential implementation errors. To improve concurrency, the granularity of the lock needs careful design. If the lock granularity is too coarse, it may restrict unnecessary concurrency; while if the granularity is too fine, it will increase the overhead of lock management. Furthermore, read-write locks still require exclusive access to resources when handling write operations, which can also lead to performance bottlenecks under frequent write operations.

[0039] 3. Observation and localization of file system problems.

[0040] When file system problems occur, related technologies lack effective methods for observation and localization. The lack of effective monitoring means that relevant debugging information cannot be detected and recorded in a timely manner when problems arise. This not only affects the speed of problem diagnosis but also increases the difficulty of maintenance and repair. Traditional logging mechanisms are often inflexible and struggle to adapt to dynamically changing workloads, especially in high-concurrency environments, where the performance overhead of logging systems is also a significant issue.

[0041] In summary, the locking mechanisms of related technologies struggle to achieve a balance between performance and fairness in high-concurrency environments. Therefore, these technologies suffer from the following problems: VFS layer lock-free concurrency protection issue: How to achieve lock-free concurrent operations at the VFS layer while ensuring the security of file operations, and avoid the performance loss and deadlock risk caused by traditional locking mechanisms.

[0042] The true concurrency problem of multiple underlying file systems: How to enable the VFS layer to support true concurrent operations of multiple underlying file systems and fully utilize the hardware concurrency capabilities.

[0043] The problem of precise control over the lifecycle of resource descriptors: How to precisely control the entire lifecycle of resource descriptors from allocation to release, and avoid race conditions and resource leaks.

[0044] The challenge of efficient implementation in RTOS / embedded environments: How to implement an efficient file system concurrency protection mechanism in resource-constrained RTOS / embedded environments.

[0045] Automatic file system problem location: How to achieve automatic detection and accurate location of file system problems without affecting system performance.

[0046] Based on this, embodiments of this application provide a method, apparatus, device, medium, and program product for executing resource operation requests. This method can integrate key information (such as descriptor state information and lock state information) into a single resource descriptor, ensuring data consistency. Furthermore, by integrating verification and resource operation steps into an indivisible whole through atomic operations, this method can quickly and accurately process these requests while ensuring data consistency and operation legality, thereby improving the system's concurrent processing capabilities.

[0047] The method for executing operation requests for resources provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0048] Figure 1 This is a schematic flowchart illustrating a method for executing a resource operation request according to an embodiment of this application. Figure 1 As shown, the method may include steps S110 and S120.

[0049] Steps S110 and S120 describe the execution pattern for a single operation request (such as a read / write operation).

[0050] S110, in response to the resource operation request, obtain the information of the descriptor status and lock status in the resource descriptor corresponding to the resource; Resource operation requests can include read operation requests, write operation requests, etc.

[0051] For example, before step S110, a resource descriptor needs to be allocated for the resource. For instance, in a Virtual File System (VFS), a resource descriptor (fd) is allocated to a file whenever it is opened. Even if the same underlying file is opened multiple times, the VFS allocates a unique resource descriptor for each open operation. Each resource descriptor is associated with a file pointer resource, which is used to track the file's open state and current access position.

[0052] For example, the VFS layer manages the allocation of resource descriptors, maintains the state of open files, and uses the mount point information contained in the file pointers to call the interface of the underlying physical file system, thereby enabling file operations. This allows VFS to provide a unified resource operation interface for upper-layer applications while hiding the specific implementation details of the underlying file system.

[0053] A resource descriptor can consist of data from multiple fields, such as a first field and a second field. The first field includes information about the descriptor's state, and the second field includes information about the lock's state.

[0054] It should be noted that, according to the inventors' research, the resources or processes that need protection in the VFS layer include: resource descriptor table management. Due to the short execution time, spin locks are used for resource management to avoid the overhead of context switching. For each file operation, without protection, unpredictable errors will occur in a high-concurrency environment. For example, if a file is closed during execution, the file pointer resource corresponding to the resource descriptor has already been released, and the file system will malfunction if this occurs. Another example is when a file is opened with a specified resource descriptor (fd), and other threads perform file read / write operations, the file pointer resource corresponding to the resource descriptor has not yet been successfully configured, and the file system will malfunction if this occurs. Regarding file operation protection, spin locks are suitable for short-term lock holding and are therefore unsuitable. Related technologies use mutexes and read-write locks. However, both have limitations in high-concurrency environments, where frequent thread switching can severely impact system response time and performance. Mutexes, in particular, severely impact performance because they allow only one thread to exclusively hold the resource. Because the VFS layer manages multiple underlying physical file systems, using mutex locks would mean that only one underlying physical file system can be operated on at a time. However, if multiple physical file systems correspond to different hardware, concurrent operations are supported. The use of mutex locks limits effective concurrency and impacts performance. The resource descriptor provided in this application can solve this problem. The resource descriptor provided in this application can protect file operations without affecting their performance.

[0055] In the Virtual File System (VFS) layer, various identifiers are defined for the states of different resource operations (or file operations). Each identifier corresponds to a specific operation state, thereby enabling precise identification and differentiation of each stage of file system activity. For example, a resource descriptor includes a first field containing information about the descriptor's state: identifier 000 indicates idle; identifier 001 indicates descriptor allocation in progress; identifier 010 indicates ready to open; identifier 011 indicates closing, and so on.

[0056] For example, the "resource descriptor" can be designed as a 32-bit unsigned integer (uint32_t). This integer, as a bitfield, is internally divided into different fields, each carrying specific state information. Therefore, multiple states can be processed in a single atomic operation. All modifications to the resource descriptor are performed through atomic compare-and-swap (CAS) operations, thus ensuring the indivisibility of the operations and achieving a lock-free design.

[0057] Specifically, after allocating a corresponding resource descriptor to a resource, upon receiving an operation request for the resource (such as a read operation request / write operation request), the information of the descriptor status and lock status in the resource descriptor can be obtained. For example, the descriptor status is open and ready, and the lock status is unlocked.

[0058] S120: Through atomic operations, the legality of the operation request is verified based on the information of the descriptor state and the lock state to obtain the first verification result; if the first verification result is successful, the operation request is executed on the resource.

[0059] Here, "atomic" means indivisible. An atomic operation is an operation that cannot be interrupted by other threads or processes during its execution; it either succeeds completely or fails completely, without any intermediate states. The entire step S120 is an atomic comparison and swap (CAS) operation. This operation cannot be interrupted by other threads or processes during its execution; it either succeeds completely or fails completely, without any intermediate states.

[0060] Atomic operations are hardware-level instructions provided by the CPU. They are indivisible and can complete a read-modify-write operation within a single instruction, without the need for additional lock protection. The advantages of this mechanism are: Lock-free design: Completely avoids traditional locking mechanisms such as mutexes and read-write locks, eliminating the risk of deadlock; High performance: Atomic operations execute extremely quickly, 10-100 times faster than traditional locking mechanisms; No context switching: Atomic operations do not cause thread blocking or waking, avoiding context switching overhead; Hardware-level guarantee: The atomicity of the operation is guaranteed by the CPU hardware, ensuring extremely high reliability.

[0061] It should be noted that the lock-free VFS concurrency protection mechanism based on atomic operations provided in this application abandons the traditional locking mechanism and instead adopts a state machine model based on hardware atomic instructions to implement concurrency protection for file operations, thereby significantly improving system performance while ensuring security. The object of the atomic operation is a resource descriptor.

[0062] Specifically, before executing an operation request (such as a read / write operation), the validity of the operation request is checked, and then the operation request is executed or rejected based on the validity result. Specifically, this can be achieved through an atomic operation: "Based on the information of the descriptor state and the lock state, the validity of the operation request is verified to obtain a first verification result (for example, if the descriptor state is open and ready and the lock state is closed, the first verification result is determined to be valid; if the descriptor state is not open and ready, or the lock state is open, the first verification result is determined to be verification failure). Then, if the first verification result is successful, the operation request is executed on the resource; otherwise, if the first verification result is failure, the operation request on the resource is rejected." The entire atomic operation will not be interrupted by other threads or processes during execution; it either executes completely successfully or not at all, without any intermediate states.

[0063] According to the resource operation request execution method provided in this application embodiment, upon receiving a resource operation request, the method obtains the descriptor state information and lock state information from the resource descriptor corresponding to the resource, and then performs an atomic operation: based on the descriptor state information and lock state information, the legality of the operation request is verified, and if the verification is successful, the operation request is executed on the resource. This atomic operation will not be interrupted by other threads or processes during execution; it either executes completely successfully or not at all, without any intermediate states. This application embodiment integrates key information (such as descriptor state information and lock state information) into a single resource descriptor, ensuring data consistency. Furthermore, by integrating the verification and resource operation steps into an inseparable whole through atomic operations, it can quickly and accurately process these requests while ensuring data consistency and operation legality, thus improving the system's concurrent processing capabilities.

[0064] The following describes the specific process of resource descriptor allocation and operation request validity verification in the resource operation request execution method provided in the embodiments of this application.

[0065] It should be noted that before step S110 is executed, a resource descriptor needs to be allocated to the resource.

[0066] In some embodiments, such as Figure 2 As shown, before step S110 responds to the resource operation request and obtains the information of the descriptor status and lock status in the resource descriptor corresponding to the resource, the execution method of the resource operation request may further include steps S131 and S132.

[0067] S131, in response to a resource descriptor allocation request, retrieve a resource descriptor whose status is idle from the resource descriptor table.

[0068] For example, when a user requests to open a resource, an allocation request for the resource descriptor of that resource is automatically generated.

[0069] A resource descriptor whose status is idle refers to a resource descriptor whose status is idle. For example, if the data in the status field is 000, it indicates that the resource is idle.

[0070] S132, allocate a resource descriptor to the resource and change the state of the descriptor in the resource descriptor from idle state to open ready state.

[0071] Specifically, when a user requests to open a resource, a resource descriptor allocation request for that resource is automatically generated. Then, a resource descriptor with an idle state can be obtained from the resource descriptor table. Next, the resource descriptor is allocated to the resource. After the resource descriptor allocation is completed, the descriptor state in the resource descriptor is changed to the open ready state (such as 010).

[0072] For example, during the allocation of a resource descriptor, the descriptor status in the resource descriptor can be changed from an idle state (e.g., 000) to a descriptor being allocated (e.g., 001), and then after the resource descriptor allocation is completed, the descriptor status in the resource descriptor can be changed from a descriptor being allocated (e.g., 001) to an open ready state (e.g., 010).

[0073] For example, a "resource descriptor" is a 32-bit unsigned integer (uint32_t). This integer, as a bitfield, is internally divided into different fields, each carrying specific state information, thus allowing multiple state information to be processed in a single atomic operation. This 32-bit resource descriptor itself is a highly condensed "system state snapshot." When a file system failure occurs, by analyzing the instantaneous value of this 32-bit identifier corresponding to the file descriptor in the crash dump, the problem can be accurately analyzed and located without introducing any additional monitoring overhead. For example, the definition of a resource descriptor is shown in Table 1.

[0074] Table 1 As shown in Table 1, a resource descriptor includes a State field, Lock Flags field, Active Op Counter field, and Generation field. The purpose of the resource descriptor is: 1) Information integration enables single-atom operations.

[0075] The core of the lock-free programming provided in this application is to use a single atomic instruction (such as a CAS atomic compare and swap instruction) provided by the CPU to update the state. In order to complete complex state transitions (e.g., checking the state, incrementing a counter, setting a flag) in a single operation, all relevant information must be packaged into a data unit that can be processed by an atomic instruction (such as a 32-bit or 64-bit integer).

[0076] If states, counters, lock flags, etc., are scattered across multiple variables, traditional locks (such as mutexes) are needed to protect their consistency, which defeats the purpose of "lock-free" and "high-performance" in this application's embodiments. Integrating all information into a single resource descriptor is the fundamental prerequisite for achieving lock-free concurrency control.

[0077] 2) Clear separation of state and count.

[0078] By establishing a separate State field, the system's logic becomes clearer and more efficient. Determining whether a file is ready requires checking only one independent field. This makes the state transition logic simpler, less prone to errors, and results in higher code execution efficiency.

[0079] 3) Counter design for high-concurrency scenarios.

[0080] File systems, especially in servers or complex embedded systems, may face a large number of concurrent read and write requests. Therefore, 16 bits are allocated to the Active Op Counter field, enabling it to support up to 65,535 concurrent operations. This ensures the availability and scalability of this embodiment in high-concurrency scenarios and prevents the counter from becoming a performance bottleneck due to overflow.

[0081] 4) Solve specific race conditions.

[0082] In concurrent systems, a typical race condition exists between read operations / write operations and close operations. One thread might initiate a new read operation / write operation while another thread has started executing the close procedure but has not yet completed it.

[0083] The Lock Flags field (specifically CLOSE_LOCK) was introduced precisely to solve this problem. When a thread decides to close a file, it first atomically sets the CLOSE_LOCK lock flag to 1. Afterward, any new read / write requests will be rejected when the resource descriptor is checked because the lock flag is set to 1, thus ensuring the "graceful" execution of the close process and preventing resource state corruption.

[0084] 5) Improve the long-term reliability of the system (ABA problem).

[0085] In a long-running system, a resource descriptor may be allocated, used, and released, and then its storage space may be reallocated to a new file operation. This can lead to two allocations resulting in the same resource descriptor value, i.e., the ABA problem (value A becomes value B, and value B becomes value A again).

[0086] Introducing a generation field solves this problem. The version number increments each time a resource descriptor is reassigned. This ensures that even if the status and count value happen to revert to an older value, the complete 32-bit identifier will always be different due to the version number. This guarantees the robustness and reliability of the system under long-term, high-load operation.

[0087] In this embodiment, multiple identifiers are defined for the states of various file operations within the Virtual File System (VFS) layer. Each identifier corresponds to a specific operation state, thereby achieving precise identification and differentiation of each stage of file system activity and ensuring file system security. Ultimately, this covers all critical steps in file processing from initialization to completion. This state differentiation mechanism can be used to manage critical operations such as opening, creating, reading, and writing files, improving the file system's concurrency performance and resource protection capabilities while simplifying the complexity of locking mechanisms. Thus, file operations are protected without affecting their performance. Furthermore, all modifications to the resource descriptor are performed atomically (such as atomic compare-and-swap instructions, CAS), ensuring the indivisibility of operations and achieving a lock-free design.

[0088] In some embodiments, such as Figure 3 As shown, the resource descriptor also includes version number information; after allocating a resource descriptor for the resource in step S132 and changing the descriptor status in the resource descriptor from idle to open and ready, the method for executing the operation request of the resource may further include step S133: S133, Update the version number information in the resource descriptor.

[0089] Specifically, after allocating resource descriptors, the version number of the resource descriptors can be updated. For example, V1.0 can be changed to V2.0 to ensure the uniqueness of resource descriptors and prevent ABA problems.

[0090] In this embodiment, the version number is incremented each time a resource descriptor is reallocated from the "idle" state. This solves the ABA problem, prevents reclaimed and reused resource descriptors from being misjudged as old descriptors, and ensures the robustness and reliability of the system under long-term, high-load operation.

[0091] In some embodiments, such as Figure 4 As shown, the first verification result is that when the verification is successful, the descriptor state is in the open ready state and the lock state is in the unlocked state; S120 verifies the legality of the operation request through atomic operations based on the information of the descriptor state and the lock state, and obtains the first verification result; if the first verification result is successful, the operation request is executed on the resource, which may include step S121: S121, through atomic operations, the legality of the operation request is verified based on the information of the descriptor state and the lock state to obtain the first verification result; if the first verification result is successful, the operation request is executed on the resource, and the descriptor state in the resource descriptor is changed from the open ready state to the actively used state.

[0092] This application embodiment uses atomic operations to perform: validating the legality of the operation request, executing or rejecting the operation request, and changing the status of the descriptor in the resource descriptor from the open and ready state to the actively used state when executing the operation request, which can ensure data consistency and operation legality.

[0093] The following describes the specific application of the active operation count value in the resource descriptor in the method for executing operation requests for resources provided in the embodiments of this application.

[0094] It should be noted that, through research, the inventors discovered that related technologies lack effective methods for observing and locating problems when file systems encounter issues. Traditional logging mechanisms are often inflexible and struggle to adapt to dynamically changing workloads, especially in high-concurrency environments where the performance overhead of logging systems is a significant concern. Therefore, related technologies lack an effective monitoring method for observing and locating problems. This application's embodiment achieves real-time monitoring of the file system operation status by updating counter values ​​in real time. By accurately recording the number of calls to each file operation interface, the root cause of the problem can be accurately located. It is also applicable to locating file system problems in multi-threaded or multi-process environments. By configuring a counter for each file operation interface and determining the file system status based on the counter value, rapid problem location is achieved, greatly improving the efficiency and accuracy of file system maintenance. This effectively detects the file system status without impacting performance.

[0095] For example, the resource descriptor includes: a status field, a lock flag field, an active operation count field, a version number field, etc. The number of currently executing / active read / write operations determines the active operation count value. For instance, the active operation count value is incremented by one when an operation request is executed and decremented by one after the operation request is completed. The file system status can be determined based on the active operation counter value. Furthermore, a close request can be allowed when the active operation count value is 0, and a close request can be rejected when the active operation count value is greater than 0, ensuring that the file system is not abnormally closed during execution.

[0096] In some embodiments, such as Figure 5 As shown, the resource descriptor also includes an active operation count; S120 verifies the legality of the operation request through atomic operations based on the information of the descriptor state and the lock state, and obtains a first verification result; if the first verification result is successful, the operation request is executed on the resource, which may include step S122: S122, through atomic operations, the legality of the operation request is verified based on the information of the descriptor state and the lock state to obtain the first verification result; if the first verification result is successful, the operation request is executed on the resource, and the active operation count value in the resource descriptor is added to a preset value (such as incrementing by one). The method for executing the operation request for this resource may further include step S140: S140, after the operation request is completed, subtract a preset value (e.g., decrement by one) from the active operation count value in the resource descriptor.

[0097] This application's embodiments employ an active operation counter design. Each file operation interface is configured with an active operation counter to record the number of times that interface is called, i.e., how many threads are currently using the resource. In other words, the number of read and write operations determines the count value. For example, if 5 threads are performing read or write operations on the resource, the active operation count is 5. Atomic operations are used to update the counter value, ensuring that the update is indivisible, thereby avoiding data inconsistency issues during concurrent updates. Querying the current counter value facilitates monitoring and analysis, and the overhead of counter updates is very small, not affecting file system performance.

[0098] In some embodiments, If the active operation count in a resource descriptor is not equal to the preset initial value (e.g., the initial value is 0), the descriptor state in the resource descriptor is in an actively used state. When the active operation count in a resource descriptor is equal to the initial value, the descriptor state in the resource descriptor is open and ready.

[0099] For example, the initial value of the active operation count is 0. Through atomic operations: when the active operation count is greater than 0 (indicating that a read / write operation is being performed), the descriptor state in the resource descriptor can be changed to the actively used state; when the active operation count is 0 (indicating that no read / write operation is being performed), the descriptor state in the resource descriptor can be changed from the actively used state to the open-ready state.

[0100] This application's embodiments protect read / write operations by using an active operation count. The active operation count value is modified through atomic operations, and this operation is not interrupted, ensuring the consistency and integrity of the resource descriptor. Furthermore, a counter is configured for each file operation interface, which can monitor the file system's operating status in real time and automatically detect and locate file system problems.

[0101] In some embodiments, such as Figure 6 As shown, the method for executing the operation request for this resource may further include step S150: S150, in response to a resource close request, the validity of the close request is verified by an atomic operation based on the active operation count value in the resource descriptor, and a second verification result is obtained; if the second verification result is successful, the lock state in the resource descriptor is changed from an unlocked state to a locked state, and the close request is executed.

[0102] Specifically, locking is required when closing a resource, which means changing the lock state in the resource descriptor to the locked state (e.g., setting it to 1). However, before changing the lock state, the active operation count in the resource descriptor must be at its initial value (e.g., an initial value of 0). If the active operation count in the resource descriptor is at its initial value, it means the close request is valid. Only then can the lock state in the resource descriptor be changed to the locked state, and the close request be executed. Changing the lock state in the resource descriptor to the locked state effectively prevents new operations from interfering with files that are about to be closed or are being closed.

[0103] For example, during the execution of a close request, the descriptor status in the resource descriptor can be changed to a closed state.

[0104] For example, a resource descriptor can be released after the resource is closed.

[0105] For example, when a file is opened / closed, the descriptor status in the resource descriptor is set to "opening / closing" to prevent other threads from attempting to operate on the same resource descriptor simultaneously, thus preventing concurrency exceptions. This implements file open / close protection.

[0106] This application's embodiments ensure the "graceful" closing process by using the atomic operation of "checking the count value first, then locking," that is, waiting for the existing operation to complete while preventing new operations from entering, and finally safely reclaiming resources, thus resolving the race condition between the read operation / write operation and the close operation.

[0107] In some embodiments, such as Figure 7 As shown, step S150 involves validating the close request based on the active operation count value in the resource descriptor to obtain a second validation result, which may include steps S151 and S152: S151, if the active operation count value in the resource descriptor is equal to the initial value (e.g., equal to 0), the second verification result is determined to be successful; S152, if the active operation count value in the resource descriptor is greater than the preset initial value (e.g., greater than 0), the second verification result is determined to be a verification failure.

[0108] For example, if the active operation count in the resource descriptor is not 0 (indicating that other threads are performing read / write operations), the second verification result is a verification failure, and if the second verification result is a verification failure, the resource close request is rejected.

[0109] This application embodiment can verify the validity of a close request by using the active operation count value in the resource descriptor, thus resolving the race condition between read / write operations and close operations.

[0110] In one example, the descriptor state transition graph for a resource descriptor is as follows: Figure 8 As shown, Figure 8 This document details how to use a 32-bit atomic identifier (or resource descriptor) to protect the entire lifecycle of a file, prevent race conditions in concurrent operations, and achieve lock-free, efficient, and secure file access. Figure 8 As shown, the process of changing the state of a descriptor in a resource descriptor is as follows: 1) In response to a resource descriptor allocation request, obtain a resource descriptor whose descriptor state is idle (state0).

[0111] 2) Allocate the resource descriptor to the resource and change the descriptor state in the resource descriptor from idle state to allocated state (state1).

[0112] 3) After the resource descriptor allocation is completed, the descriptor status in the resource descriptor is changed from the allocation state (state1) to the open and ready state (state2).

[0113] For example: the process of initializing and securely allocating resource descriptors is as follows: When a user requests to open a file, it means the user is issuing a request for a resource descriptor (fd), and the system needs to allocate a resource descriptor (fd) for the file. First, the system searches for a free resource descriptor in the resource descriptor table. Once found, the system performs an atomic compare-and-swap (CAS) operation to update the descriptor's 32-bit identifier.

[0114] Check: Ensure that the resource descriptor is still in the expected "idle" state.

[0115] Update: If the check passes, the State field is updated from idle to allocated, and the Generation field in the resource descriptor is incremented. Incrementing the version number ensures that even if the descriptor is immediately released and reallocated, old, deferred operations cannot affect the new file instance, thus avoiding the ABA problem. The entire allocation process is protected by atomic instructions, eliminating the risk of multiple threads simultaneously allocating the same descriptor.

[0116] After the underlying resources (such as memory buffers) are allocated, the State field is updated to the open and ready state again through atomic operations.

[0117] 4) In response to read / write requests for resources, the following atomic operations are performed: If the resource descriptor is in the open-ready state (state2) and the lock is unlocked, the read / write request is executed, and the resource descriptor state is changed from open-ready (state2) to actively used (state3+), and the active operation count in the resource descriptor is incremented. After the read / write request is executed, the active operation count in the resource descriptor is decremented, and when the active operation count reaches 0, the resource descriptor state is changed from actively used (state3+) to open-ready (state2). If the resource descriptor state is not open-ready (state2) or the lock is locked, the read / write request is rejected.

[0118] For example, the process of initiating access control for read / write operations is as follows: When a thread is ready to perform a read or write operation on a file that is in the "open and ready" state, it needs to ensure that the operation can only begin if the file has not been closed.

[0119] Reading the current resource descriptor: The thread first reads the complete 32-bit resource descriptor of the file descriptor.

[0120] Perform an atomic increment operation: The thread attempts to perform an atomic Compare-And-Swap (CAS) operation to increment the Active Op Counter.

[0121] Check (or compare): The success of the comparison and swap CAS operation of this atom is contingent on the resource descriptor's State field being open and ready, and the CLOSE_LOCK bit in the Lock Flags not being set (e.g., being 0).

[0122] Update (or swap): If the check passes, the active operation count is incremented by one.

[0123] Access decision: If the CAS operation succeeds, the thread gains access and performs concurrent read / write operations. If the CAS operation fails (because the file state is not open and ready or the lock flag CLOSE_LOCK has been set), it means that the file is being closed, and the current read / write request is rejected, thus preventing new operations from being initiated during the closing process.

[0124] Protection mechanism: By checking the status and lock flags before incrementing the count, it effectively prevents new operations from interfering with files that are about to close or are being closed.

[0125] For example, the process of performing concurrent read / write operations is as follows: Once granted access, the thread can safely perform actual file I / O.

[0126] Perform I / O: The thread performs data reading or writing.

[0127] Status indicator: During this period, because the active operation count is greater than 0, the resource descriptor's state appears to be State3+: Actively in Use. This explicitly informs other parts of the system (especially shutdown operations) that the file is being actively used.

[0128] Protection mechanism: A non-zero active operation count acts like a "Do Not Disturb" signal, which is the key criterion for determining whether a shutdown operation can continue.

[0129] For example, the process of safely exiting a read / write operation is as follows: Once a read / write operation is complete, the thread must safely "check out" and notify the system that it has finished the operation.

[0130] Perform an atomic decrement operation: The thread performs an atomic CAS operation once, decrementing the active operation count by one.

[0131] State regression: When the active operation count is reduced to 0, the resource descriptor's state regresses from the actively used state to the open and ready state, indicating that there are currently no operations in progress.

[0132] Protection mechanism: The atomic decrementing of the count ensures the accuracy of the count value. When the last concurrent operation completes, the count value is precisely zeroed, creating conditions for the shutdown operation.

[0133] 5) In response to a resource close request, an atomic operation is performed: if the active operation count in the resource descriptor is 0, the lock state in the resource descriptor is changed from unlocked to locked, and the close request is executed, while the descriptor state is changed to the closing state (state4); if the active operation count in the resource descriptor is greater than 0, the close request is rejected.

[0134] 6) After the close request is completed, release the resource descriptor and set the descriptor to an idle state (state0).

[0135] Example land, The process of closing files and reclaiming resources is as follows: When a user requests to close a file, it is necessary to ensure that the resource can only be safely closed (resource cleanup and reclamation) after all read / write operations have been completed.

[0136] Attempt to acquire the closing lock: The closing thread attempts to perform an atomic CAS operation to set CLOSE_LOCK to 1 and change the descriptor state to the closing state.

[0137] Check: This operation is successful only if the active operation count is 0.

[0138] Update: If the check passes, the CLOSE_LOCK bit in the Lock Flags will be set, and the State field will be updated to the closed state.

[0139] Prevent new operation and wait: If the CAS operation fails (because the count is not zero), the closed thread will wait a short time before retrying until all active operations are completed.

[0140] Once the CAS operation succeeds, the CLOSE_LOCK lock flag will prevent any new read / write operations.

[0141] Perform resource reclamation: Since there are no active operations and new operations are blocked, it is now safe to release all related resources such as file handles and memory buffers.

[0142] Final Reset: After the resource is released, a final atomic write operation resets the entire 32-bit identifier to the initial "Idle" state, the lock state to the unlocked state, the count value to 0, etc., so that it can be reallocated.

[0143] The advantages of the embodiments of this application are summarized as follows: 1) Design and state transition control of resource descriptor state machine: State transitions are protected by the design of state machine and atomic operations, which reduces the dependence on mutex locks and read-write locks and improves concurrency performance.

[0144] 2) Optimization of protection mechanism: The update operation of the state machine is protected by atomic operations, which reduces the overhead of context switching and improves the system response time and performance.

[0145] 3) File open / close protection: The security of the file opening / closing process is ensured by setting the state machine, avoiding problems caused by concurrent operations.

[0146] 4) File read / write concurrency and protection: By setting up a state machine, the security and concurrency of read / write operations are ensured, thereby improving the overall performance of the system.

[0147] 5) Protection of the resource descriptor state machine: The update of the state machine is protected by atomic operations, which reduces the possibility of data races and improves the reliability of the system.

[0148] 6) Design of active operation counter: By updating the counter value in real time, the real-time monitoring of the file system operation status is realized, which improves the efficiency and accuracy of file system maintenance.

[0149] Therefore, this application proposes to improve system concurrency performance and resource protection capabilities while ensuring file system security, simplifying the complexity of locking mechanisms, and providing effective monitoring methods. In terms of performance: it completely eliminates deadlock risks, significantly improving system stability; reduces context switching overhead by over 90%; atomic operations are 10-100 times faster than traditional locking mechanisms; and supports true concurrent operations across multiple underlying file systems, ensuring real-time system response performance. In terms of functionality: it precisely controls the entire lifecycle of file descriptors, avoiding resource leaks and duplicate releases, and supports complex file operation state management. It enables automatic detection of file system problems. It accurately locates the interface and cause of problems, reducing problem location time from hours to minutes. In terms of technology: it implements lock-free concurrency protection based on atomic operations at the VFS layer, a state machine model designed for the characteristics of the file descriptor lifecycle, and an automatic problem location mechanism implemented with multi-dimensional counters.

[0150] It should be noted that the embodiments of this application are a method for high-concurrency resource protection and automatic anomaly detection of file systems based on lock-free resource descriptor state machines. The file protection process based on atomic identifiers proposed in the embodiments of this application has the following advantages: Full-cycle security: By integrating the State and Lock Flags fields into the 32-bit atomic identifier (resource identifier), illegal file read and write operations are effectively prevented when resources are not ready or are being reclaimed, ensuring the security and state consistency of the file system.

[0151] High-performance concurrent processing: Utilizing the Active Op Counter field in the resource descriptor instead of traditional locks. Threads can atomically update the counter value without waiting, greatly reducing the performance overhead caused by thread blocking and context switching, and significantly improving the file system's concurrent processing capabilities.

[0152] Atomicity and data integrity: All modifications to a single 32-bit resource descriptor are performed through atomic instructions, fundamentally eliminating data races and ensuring the integrity of state transitions and counting, making it more efficient than traditional locking mechanisms.

[0153] In summary, the embodiments of this application, by highly integrating multi-dimensional state information into a 32-bit atomic identifier (resource identifier), accurately cover the entire process of a file from creation to destruction, achieving significant improvements in the file system in three dimensions: concurrency performance, resource protection, and mechanism simplification.

[0154] Because resource identifier updates are atomic, their values ​​in memory faithfully record the last atomic operation completed before a system crash. By interpreting the combination of the four fields within the identifier, the precise state of the system at the moment of failure can be inferred. A resource descriptor state machine model reduces reliance on mutexes and read-write locks, using atomic operations only when necessary to protect file state machine update operations, thus minimizing context switching overhead.

[0155] The State field directly reveals the lifecycle stage of the file descriptor. If the State value is Closing when the system crashes, the problem is likely in the code path related to resource reclamation. If the value is Allocating, the problem may be related to resource initialization.

[0156] The state field reflects the file's status during different operations, such as idle (or uninitialized), allocated, open, ready to open, actively used (e.g., reading, writing), closing, and closed. Ensure the file state definition is clear and accurately represents the current operation stage of the file. For example: State0: The file descriptor is idle and available. State1: The file descriptor has been allocated but the resource allocation is not yet complete (allocation in progress). State2: The file is open and ready. State3+: The file is currently undergoing read / write operations (actively used), with the active operation count incrementing to indicate the number of ongoing operations.

[0157] State transition control: This application defines legal transition paths between each state to ensure the safety and consistency of state transitions. State transitions are atomic, ensuring that they are not interrupted or switched during execution. For example, see... Figure 8 Transition from State0 to State1: File descriptor allocation. Transition from State1 to State2: Resource allocation successful. Transition from State2 to State3+: Read / write operations begin. Transition from State3+ to State2: Read / write operations complete. Transition from State2 to State4: Closing operations begin. Transition from State4 to State0: Closing operations complete.

[0158] File Read / Write Concurrency and Protection: Before a read / write operation begins, a status field is set to indicate that the file is in a read / write state. This ensures that no other thread attempts to open or close the same file descriptor during the read / write process. Furthermore, if multiple file read / write operations are targeting different resource descriptors, they will not be blocked, thus enabling concurrent file read / write operations.

[0159] The Active Op Counter field directly reflects the system's concurrent load level at the moment of failure. A value of 1 indicates that the system crashed during a single operation, helping to narrow down the problem to a specific I / O operation logic. A value significantly greater than 1 (e.g., hundreds) strongly suggests that the system was under extremely high concurrent I / O pressure before the crash, and the problem may stem from resource contention, logical flaws, or performance bottlenecks under high concurrency.

[0160] Lock Flags field analysis reveals ongoing critical processes requiring special protection. If the CLOSE_LOCK flag is set while the Active Op Counter is greater than 0, this constitutes an illegal or abnormal state (normally, the Active Op Counter is ensured to be 0 before setting CLOSE_LOCK). This situation directly exposes a logical error in the system, such as an operation failing to correctly decrement the counter.

[0161] The Generation field is used to detect memory errors such as dangling pointers and use-after-free. During debugging, if the version value recorded in a file descriptor pointer held by a thread (e.g., 5) does not match the actual version value at the same location in the file descriptor table (e.g., it has become 6), it can be concluded that the thread is using an expired file descriptor that has been reclaimed and reallocated. This is crucial for locating memory-related bugs that are difficult to reproduce.

[0162] By comprehensively analyzing this 32-bit integer, this application provides a zero-cost, high-efficiency fault diagnosis method. It solidifies complex system behavior into a simple numerical snapshot, greatly reducing the difficulty of problem localization and improving the maintainability and robustness of the file system.

[0163] It should be noted that the embodiments of this application differ from related technologies in their applicable scenarios. The embodiments of this application are particularly suitable for RTOS / embedded environments, while related technologies are mainly aimed at general-purpose operating systems. The embodiments of this application possess automatic problem detection and localization capabilities through resource descriptors, a function lacking in related technologies.

[0164] In one example, this application embodiment can be applied to the OneOS Multi operating system. OneOS is an operating system designed for multiple application scenarios, featuring real-time performance, high efficiency, and security. The system boasts excellent real-time performance and security, employing a preemptive real-time kernel design that supports real-time multi-core scheduling and single-core compatibility. It also features system and application security isolation protection, ensuring stable operation in harsh environments. With its highly modular and scalable architecture, it can flexibly adapt to everything from resource-constrained embedded devices to complex high-computing-power hardware environments. It possesses a unified access method driver framework and rich middleware, providing a customized and reliable operating system platform for different application scenarios. OneOS has been used in multiple products, and the VFS virtual file system used in these products is also integrated into the OneOS operating system, protecting file security and improving performance across multiple products.

[0165] The system architecture diagram of a RISC-V-based RTOS kernel operating system is as follows: Figure 9 As shown, among the functional modules of this RTOS kernel operating system for various scenarios, the VFS virtual file system is an indispensable component. The VFS virtual file system standardizes the unified allocation of file descriptor resources by kernel threads and user processes, and maintains the state of open files. It uses the mount point information contained in the file pointer to call the interface of the underlying physical file system, thereby implementing file operations. This design allows VFS to provide a unified file operation interface for upper-layer applications while hiding the specific implementation details of the underlying file system.

[0166] The embodiments of this application can be applied to the VFS virtual file system in the OneOS operating system. While ensuring file system security, it can improve the system's concurrency performance and resource protection capabilities, simplify the complexity of the locking mechanism, and provide effective monitoring methods.

[0167] It should be noted that in the design of Virtual File System (VFS), related technologies typically rely on mutex locks or file read-write locks provided by the operating system to ensure the security of file system operations. However, this proposal abandons this traditional approach and instead adopts a file descriptor state machine to control the flow of VFS layer interface operations, ensuring security without sacrificing performance. The solution of this application embodiment demonstrates significant advantages in the embedded field, especially in applications requiring high real-time performance and high security.

[0168] While related open-source real-time operating system (RTOS) projects are powerful, their file system designs often lack detailed protection for file operations at the VFS layer. Tests have shown that under high concurrency, these systems are highly susceptible to abnormal behavior, increasing the risk of data corruption or even system crashes.

[0169] Compared with the method of using a file state machine in the embodiments of this application, the mutex lock or file read-write lock method is more efficient. The embodiments of this application are suitable for high real-time and high security application scenarios.

[0170] In applications with high real-time and high security requirements, such as industrial automation, medical equipment, and aerospace, the technical solution provided in this application can significantly improve the stability and reliability of the VFS virtual file system. For these industries, data integrity and fault-free system operation are crucial, and this application can meet their stringent requirements, thus possessing broad commercial application prospects.

[0171] In summary, this application provides a more efficient and secure file system protection mechanism, which not only fills the gap in the current market for insufficient RTOS file system protection, but also provides strong support for applications with high real-time and high security requirements.

[0172] Based on the same inventive concept, such as Figure 10 As shown in the figure, this application embodiment also provides an execution device for a resource operation request. The device 1000 may include an acquisition module 1010 and an execution module 1020: The acquisition module 1010 is used to obtain information about the status of the descriptor and the lock status in the resource descriptor corresponding to the resource in response to the operation request of the resource; The execution module 1020 is used to verify the legality of the operation request through atomic operations based on the information of the descriptor state and the lock state, and obtain a first verification result; if the first verification result is successful, the operation request is executed on the resource.

[0173] In some embodiments, before the acquisition module acquires information about the descriptor status and lock status in the resource descriptor corresponding to the resource in response to an operation request for the resource, the apparatus further includes an allocation module: The acquisition module is also used to retrieve a resource descriptor whose status is idle from the resource descriptor table in response to a resource descriptor allocation request. The allocation module is used to allocate resource descriptors to resources and change the status of the descriptors in the resource descriptors from idle to open and ready.

[0174] In some embodiments, the resource descriptor further includes version number information; after the allocation module allocates a resource descriptor to the resource and changes the descriptor status in the resource descriptor from an idle state to an open-ready state, the apparatus further includes an update module: The update module is used to update the version number information in the resource descriptor.

[0175] In some embodiments, when the first verification result is successful, the descriptor state is in an open-ready state and the lock state is in an unlocked state; the execution module is used to execute an operation request on the resource when the first verification result is successful, specifically for: If the first verification result is successful, execute the operation request for the resource and change the status of the resource descriptor from the open and ready state to the actively used state.

[0176] In some embodiments, the resource descriptor further includes an active operation count value; the execution module is configured to execute an operation request on the resource if the first verification result is successful, specifically for: If the first verification result is successful, execute the operation request for the resource and add a preset value to the active operation count value in the resource descriptor. The device also includes a computing module: The calculation module is used to subtract a preset value from the active operation count in the resource descriptor after the operation request has been executed.

[0177] In some embodiments, If the active operation count in a resource descriptor is not equal to the preset initial value, the descriptor state in the resource descriptor is in an actively used state. When the active operation count in a resource descriptor is equal to the initial value, the descriptor state in the resource descriptor is open and ready.

[0178] In some embodiments, the device further includes: The execution module is also used to respond to a resource close request by performing an atomic operation to verify the validity of the close request based on the active operation count value in the resource descriptor, and obtaining a second verification result; if the second verification result is successful, the lock state in the resource descriptor is changed from an unlocked state to a locked state, and the close request is executed.

[0179] In some embodiments, the execution module is configured to perform a validity check on the close request based on the active operation count value in the resource descriptor, and obtain a second verification result, which can be specifically used for: If the active operation count in the resource descriptor is equal to the initial value, the second verification result is determined to be a successful verification. If the active operation count in the resource descriptor is greater than the preset initial value, the second verification result is determined to be a verification failure.

[0180] The various modules in the resource operation request execution device provided in the embodiments of this application can implement... Figures 1 to 8 The functions of each step of the execution method for the operation request of the provided resources, and the corresponding technical effects they achieve, will not be elaborated here for the sake of brevity.

[0181] Figure 11 A schematic diagram of the hardware structure of the device for executing operation requests of resources provided in an embodiment of this application is shown.

[0182] The device for executing resource operation requests may include a processor 1101 and a memory 1102 storing computer program instructions.

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

[0184] Memory 1102 may include mass storage for data or instructions. For example, and not limitingly, memory 1102 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 1102 may include removable or non-removable (or fixed) media. Where appropriate, memory 1102 may be internal or external to the execution device requesting the operation of a resource. In a particular embodiment, memory 1102 is a non-volatile solid-state memory.

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

[0186] The processor 1101 implements the method for executing operation requests for any of the resources in the above embodiments by reading and executing computer program instructions stored in the memory 1102.

[0187] In one example, the device for executing resource operation requests may further include a communication interface 1103 and a bus 1104. For example, Figure 11 As shown, the processor 1101, memory 1102, and communication interface 1103 are connected through bus 1104 and complete communication with each other.

[0188] The communication interface 1103 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0189] This device can execute the resource operation request execution method in the embodiments of this application based on the various units / components in the resource operation request execution device, thereby realizing the combination of Figures 1 to 8 The method for executing operation requests for the described resource.

[0190] Furthermore, in conjunction with the resource operation request execution method in the above embodiments, this application embodiment can provide a computer storage medium for implementation. The computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement the resource operation request execution method in any of the above embodiments.

[0191] This application also provides a computer program product in which the instructions, when executed by a processor of an electronic device, cause the electronic device to perform various processes of the execution method embodiment for implementing the operation request of any of the above-described resources.

[0192] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

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

[0194] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0195] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A method for executing a resource operation request, characterized in that, include: In response to a resource operation request, obtain information about the descriptor status and lock status in the resource descriptor corresponding to the resource; The legality of the operation request is verified through atomic operations based on the information of the descriptor state and the information of the lock state to obtain a first verification result; if the first verification result is successful, the operation request is executed on the resource.

2. The method according to claim 1, characterized in that, Before obtaining information about the descriptor status and lock status in the resource descriptor corresponding to the resource in response to an operation request for the resource, the method further includes: In response to a resource descriptor allocation request, retrieve a resource descriptor whose status is idle from the resource descriptor table; The resource descriptor is allocated to the resource, and the state of the descriptor in the resource descriptor is changed from the idle state to the open ready state.

3. The method according to claim 2, characterized in that, The resource descriptor also includes version number information; after allocating the resource descriptor to the resource and changing the descriptor status in the resource descriptor from the idle state to the open and ready state, the method further includes: Update the version number information in the resource descriptor.

4. The method according to claim 1, characterized in that, When the first verification result is successful, the descriptor state is open and ready and the lock state is unlocked. The step of executing the operation request on the resource when the first verification result is successful includes: If the first verification result is successful, the operation request is executed on the resource, and the descriptor status in the resource descriptor is changed from the open ready state to the actively used state.

5. The method according to claim 1, characterized in that, The resource descriptor also includes an active operation count; the step of executing the operation request on the resource when the first verification result is successful includes: If the first verification result is successful, the operation request is executed on the resource, and the active operation count value in the resource descriptor is added to a preset value. The method further includes: After the operation request is completed, the active operation count value in the resource descriptor is subtracted from the preset value.

6. The method according to claim 5, characterized in that, If the active operation count value in the resource descriptor is not equal to the preset initial value, the descriptor state in the resource descriptor is an actively used state. When the active operation count value in the resource descriptor is equal to the initial value, the descriptor state in the resource descriptor is open and ready.

7. The method according to claim 6, characterized in that, Also includes: In response to the resource closure request, the validity of the closure request is verified by an atomic operation based on the active operation count value in the resource descriptor, and a second verification result is obtained. If the second verification result is successful, the lock state in the resource descriptor is changed from unlocked to locked, and the close request is executed.

8. The method according to claim 7, characterized in that, The step of performing a validity check on the close request based on the active operation count value in the resource descriptor to obtain a second verification result includes: If the active operation count value in the resource descriptor is equal to the initial value, the second verification result is determined to be a successful verification. If the active operation count value in the resource descriptor is greater than the preset initial value, the second verification result is determined to be a verification failure.

9. An execution device for a resource operation request, characterized in that, include: The acquisition module is used to acquire information about the status of the descriptor and the lock status in the resource descriptor corresponding to the resource in response to the operation request of the resource. The execution module is configured to perform atomic operations to verify the legality of the operation request based on the information of the descriptor state and the information of the lock state, and obtain a first verification result; if the first verification result is successful, the operation request is executed on the resource.

10. An execution device for a resource operation request, characterized in that, The device includes: a processor and a memory storing computer program instructions; the processor, when executing the computer program instructions, implements the method for executing a resource operation request as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the method for executing a resource operation request as described in any one of claims 1 to 8.

12. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the device, the device is able to perform the execution method of the resource operation request as described in any one of claims 1 to 8.

Images