Data sharing and synchronizing method and system, electronic equipment and readable storage medium

Abstract

The invention discloses a data sharing and synchronizing method, a data sharing and synchronizing system, electronic equipment and a storage medium, and belongs to the technical field of data processing. The method comprises the following steps: firstly, in response to a buffer area application request of a first module, allocating a shared buffer area, generating a resource access handle for accessing the shared buffer area, and generating a first synchronization signal handle bound with a current use state of the shared buffer area; wherein the initial state of the first synchronization signal handle is unready. And then, the resource access handle and the first synchronization signal handle are sent to the second module, and the first synchronization signal handle in the ready state is used for indicating the second module to perform access operation on the shared buffer based on the resource access handle. According to the method and the device, the technical effects of process reusability and time sequence determination are realized, an efficient and reliable solution is provided for cross-module data interaction, and the development and maintenance cost is remarkably reduced while the system performance is improved.

Description

Technical Field

[0001] This application belongs to the field of data processing technology, specifically relating to a data sharing and synchronization method, a data sharing and synchronization system based on dual-manager collaboration, an electronic device, and a readable storage medium. Background Technology

[0002] In modern computer systems, especially in fields requiring multi-module (including multi-process, multi-device, or multi-operating system) collaboration such as multimedia and graphics processing, pipeline-based data processing has become mainstream. To improve performance, the industry commonly employs shared memory combined with asynchronous / synchronous techniques.

[0003] However, in actual engineering implementation, the above-mentioned cross-module collaboration technology has a fundamental flaw: process fragmentation. When implementing cross-module data exchange, application or driver developers must manually and actively call multiple independent and scattered kernel interfaces to connect the entire cross-module data processing flow.

[0004] This "piecework" approach places the entire burden of ensuring process correctness on the developers. Developers not only need to write a large amount of glue code, but are also highly susceptible to data access conflicts and synchronization failures due to improper timing coordination. Therefore, cross-module collaborative development is not only complex, but also prone to typical cross-module interaction problems such as data access conflicts and synchronization failures caused by improper timing coordination. Summary of the Invention

[0005] The purpose of this application is to provide a data sharing and synchronization method, a data sharing and synchronization system based on dual-manager collaboration, an electronic device, and a readable storage medium, which can solve the problems of cross-module collaborative development being not only complex, but also prone to data access conflicts and synchronization failures caused by improper timing coordination.

[0006] To solve the above-mentioned technical problems, this application is implemented as follows: In a first aspect, embodiments of this application provide a data sharing and synchronization method, applied to a data sharing and synchronization system, the method comprising: In response to the buffer request from the first module, a shared buffer is allocated, and a resource access handle for accessing the shared buffer is generated, as well as a first synchronization signal handle bound to the current usage state of the shared buffer; wherein the initial state of the first synchronization signal handle is in an unready state. The resource access handle and the first synchronization signal handle are sent to the second module, wherein the first synchronization signal handle, which is in a ready state, is used to instruct the second module to perform an access operation on the shared buffer based on the resource access handle.

[0007] Secondly, embodiments of this application provide a data sharing and synchronization system based on dual-manager collaboration, the system comprising: A buffer manager is used to allocate a shared buffer in response to a buffer request from the first module, generate a resource access handle for accessing the shared buffer, and then provide the resource access handle to the second module. A synchronization manager is used to generate a first synchronization signal handle bound to the current usage state of the shared buffer, and then provide the first synchronization signal handle to the second module; wherein the initial state of the first synchronization signal handle is in an unready state; Specifically, when the state of the first synchronization signal handle is ready, the second module performs access operations on the shared buffer based on the resource access handle.

[0008] Thirdly, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0009] Fourthly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0010] According to an embodiment of this application, in response to a buffer request from a first module, a shared buffer is allocated, and a resource access handle for accessing the shared buffer is generated, along with a first synchronization signal handle bound to the current usage state of the shared buffer; wherein, the initial state of the first synchronization signal handle is "not ready". The resource access handle and the first synchronization signal handle are sent to a second module, wherein the first synchronization signal handle, in a ready state, instructs the second module to perform an access operation on the shared buffer based on the resource access handle. This application, through a unified resource access handle and synchronization signal handle generation mechanism, transforms the traditional development model that requires manually concatenating multiple independent primitives into a standardized process. Developers only need to follow a fixed data transfer process, without needing to concern themselves with underlying shared memory mapping, cache refresh, and other implementation details, significantly reducing development complexity and error rates. The waiting mechanism based on the synchronization signal handle ensures the deterministic timing of data access, effectively avoiding data race problems. Meanwhile, by employing zero-copy shared memory and asynchronous synchronization mechanisms, redundant memory copy operations are eliminated, significantly reducing CPU (Central Processing Unit) data transport overhead and improving system throughput and processing efficiency. This application provides a unified synchronization primitive mechanism, enabling different modules to coordinate efficiently and effectively eliminating synchronization barriers between systems. This design has good universality and scalability, applicable to various cross-module and cross-system data transmission scenarios, avoiding the complexity of maintaining multiple communication mechanisms. Ultimately, it achieves the technical effects of reusable processes and deterministic timing, providing an efficient and reliable solution for cross-module data interaction, significantly reducing development and maintenance costs while improving system performance. Attached Figure Description

[0011] Figure 1 This is a flowchart illustrating the steps of a data sharing and synchronization method provided in an embodiment of this application; Figure 2 This is a structural block diagram of another embodiment of the data sharing and synchronization system based on dual-manager collaboration provided in this application; Figure 3 This is a schematic diagram of a data sharing and synchronization system based on dual-manager collaboration. Figure 4 This is a structural block diagram of an electronic device for data sharing and synchronization, according to an exemplary embodiment. Detailed Implementation

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

[0013] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0014] Data sharing and synchronization methods refer to technical solutions for transferring data and coordinating operation timing between different modules. It is an abstract working paradigm for cross-module collaboration within a computer system, focusing on solving two fundamental problems: "Where is the data?" (sharing) and "When is it available?" (synchronization). This method belongs to the fields of operating system resource management and multimedia data processing technology, aiming to replace the traditional "piecing together" implementation method. This application involves cross-process and cross-device data exchange and collaborative control. For example, in the fields of multimedia processing and operating system interaction, multiple modules process data sequentially and pass intermediate results through memory buffers.

[0015] The data sharing and synchronization system aims to solve the synchronization and efficiency challenges of cross-module and cross-device data sharing, and is the main body and core of the architecture of this method.

[0016] The data sharing and synchronization method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0017] Reference Figure 1 This document illustrates a flowchart of a data sharing and synchronization method provided in an embodiment of this application. Applied to a data sharing and synchronization system, the method may specifically include the following steps: Step 101: In response to the buffer request from the first module, allocate a shared buffer, generate a resource access handle for accessing the shared buffer, and generate a first synchronization signal handle bound to the current usage state of the shared buffer; wherein the initial state of the first synchronization signal handle is in an unready state.

[0018] In this embodiment, a buffer request is an instruction issued by the data sharing and synchronization system to request the allocation of a memory region that can be shared across modules / devices.

[0019] In this embodiment, the first module refers to the module that initiates a buffer request to the data sharing and synchronization system in a specific data processing flow. It is typically a producer or user that has data processing needs and requires a buffer to store processing results. Specifically, it actively allocates resources, fills data, and triggers synchronization. For example, GPU (Graphics Processing Unit) drivers, video capture device drivers, video decoding threads (i.e., decoders), and post-processing threads are responsible for generating raw data for downstream use. The first module can also be a coordinator or scheduler, coordinating the entire data processing pipeline and managing resources uniformly. For example, a task scheduler requests a buffer and allocates it to multiple processing units. The first module can also be a consumer, requiring a buffer to receive upstream data in pull mode. The first module can be any applicable module, and this embodiment does not limit its specific application.

[0020] In this embodiment, the core feature of the first module is initiating an application, rather than a fixed functional role. The system does not care about the applicant's identity; it only responds to requests and allocates resources. This reflects the system's versatility and flexibility.

[0021] In this embodiment, the second module is a subsequent module that needs to access the shared buffer and relies on the operations performed by the first module (or other modules). It is typically a consumer that uses the data produced by the first module. For example, a display rendering engine, audio playback unit, or other processing unit is responsible for receiving and utilizing the data to complete corresponding functions. The second module can be any applicable module, and this embodiment does not impose any limitations on it.

[0022] In the embodiments of this application, the shared buffer is a memory area that can be accessed by multiple modules. It can be a segment of memory in the system's physical memory that can be directly accessed by multiple hardware modules (such as CPU, GPU, display controller, ISP (Image Signal Processor) etc.), and is the basis for realizing zero-copy data sharing.

[0023] In this embodiment, a resource access handle is a credential used to identify and access a shared buffer. Specifically, it is typically represented by a file descriptor (fd), serving as a unified interface for user-mode programs or kernel modules to operate on the shared buffer.

[0024] Taking the Linux kernel as an example, this mechanism is implemented through the dma-buf (Direct Memory Access Buffer) subsystem. dma-buf is the core mechanism in the Linux kernel used to support cross-device and cross-driver memory sharing. Its workflow can be briefly summarized as follows: a kernel module (such as a GPU driver) can export its allocated physical memory as a dma-buf object; this dma-buf object can further generate a corresponding file descriptor, i.e., a dma-buf fd; this dma-buf fd can serve as a general resource access handle, securely passed between processes or kernel components; after other modules import this handle, they can directly map and access the same physical memory, thereby achieving efficient zero-copy data sharing. Therefore, in this application, the resource access handle, in its specific implementation, corresponds to the dma-buf fd, which acts as a standardized medium for accessing the shared buffer, providing a unified and secure access foundation for cross-module data interaction.

[0025] In this embodiment, a synchronization signal handle is a transitive synchronization object handle used to characterize the completion status of an asynchronous operation. Specifically, it typically manifests as a file descriptor, serving as a unified interface and operational credential for user-mode programs or kernel components to access underlying synchronization signals (such as DMA-fence). The initial state of the synchronization signal handle is not ready, indicating that data is not yet ready.

[0026] One specific implementation is based on the synchronization primitive mechanism of Linux (an operating system kernel), and its core relationships and working methods are as follows: The dma-fence object in the kernel is a core synchronization primitive that represents the completion status of hardware operations (such as GPU rendering tasks), and is responsible for recording the operation status and providing a notification mechanism.

[0027] The sync_file mechanism can encapsulate the dma-fence into a file descriptor (i.e., sync-fd), thereby generating a synchronization signal handle that can be passed in user space.

[0028] Producers can attach an incomplete signal based on dma-fence to the shared buffer when an operation is not completed, and pass the corresponding sync-fd to the consumer, thus avoiding blocking and waiting.

[0029] When the hardware operation is actually completed, the dma-fence is triggered to a completed state. Consumers can detect this event by waiting for the sync-fd and safely access the buffer at the correct time.

[0030] This mechanism enables explicit synchronization across modules, effectively coordinating the timing of asynchronous hardware access.

[0031] In this embodiment, binding to the current usage state of the shared buffer refers to the association between the synchronization signal and a specific usage stage of the shared buffer (such as write completion). For example, using dma-fence, synchronization primitives are attached to the shared buffer: when the producer has not completed an operation, it attaches an incomplete signal to the shared buffer, and then can directly hand the shared buffer over to the downstream module without blocking and waiting; when the hardware operation is completed, the consumer is notified to continue processing through the synchronization signal handle.

[0032] In this embodiment, a unified resource management layer establishes the physical foundation and synchronization mechanism for data sharing. When a first module (such as a producer) needs to produce data, it no longer directly calls the scattered underlying primitives, but instead requests resources from the unified resource management layer. This layer allocates shared buffers in a centralized manner, generates resource access handles, and creates corresponding synchronization signal handles, thus avoiding the problems of primitive dispersion and splicing from the source.

[0033] In this embodiment, a unified resource management layer provides a one-stop allocation and export service for shared buffers, and automatically generates associated resource access handles and synchronization signal handles. This integrates the process that originally required the concatenation of multiple independent primitives into a single standardized operation, thereby avoiding redundant memory copying and timing uncertainty issues from the source.

[0034] In one specific implementation, a buffer manager (BufMgr) and a synchronization manager (SyncMgr) form the core architecture, providing a unified functional entry point and standardized processing flow: In response to a request from the first module, the buffer manager allocates a shared buffer and generates a resource access handle for accessing the shared buffer, while the synchronization manager generates a synchronization signal handle bound to the current usage state of the shared buffer; the initial state of the synchronization signal handle is "not ready". This upgrades the existing primitive-based implementation to a framework-based orchestration, improving process reusability and system manageability.

[0035] The buffer manager is responsible for the unified management of shared memory buffers across modules. Running as a kernel module, the buffer manager provides a standard interface for allocating and exporting shared buffers.

[0036] The synchronization manager provides a unified asynchronous synchronization mechanism. As a kernel character device implementation, the synchronization manager provides services to user space through ioctl (Input / Output Control) commands, supporting operations such as creating new fences and returning the corresponding file descriptors (i.e., synchronization signal handles).

[0037] The buffer manager and synchronization manager, as intermediate service modules, can be considered as resource management services provided by the operating system. The first and second modules exchange data and synchronize timing by calling the interfaces of the buffer manager and synchronization manager (such as ioctl or API calls), achieving loosely coupled parallel processing between modules.

[0038] Through the collaborative work of the buffer manager and synchronization manager, a unified allocation and export service is provided. Developers only need to make a single request to obtain a complete set of resource access handles and synchronization signal handles, transforming the piecemeal implementation into a one-stop acquisition.

[0039] By pre-establishing the binding relationship between synchronization signal handles and shared buffers, and ensuring timing determinism at the framework level, developers can confidently perform zero-copy operations. The strong association between resource access handles and synchronization signal handles ensures that data will not be accessed before it is ready, fundamentally eliminating the need for protective copying.

[0040] Step 102: Send the resource access handle and the synchronization signal handle to the second module, wherein the first synchronization signal handle in the ready state is used to instruct the second module to perform access operations on the shared buffer based on the resource access handle.

[0041] In this embodiment, the resource access handle and the synchronization signal handle are sent to the second module. This can be implemented in various ways, and this embodiment does not limit the specific implementation.

[0042] For example, the system might first send the handle to the first module, which then forwards it to the second module. Alternatively, the system might send the handle directly to the second module. Another example is that the system stores the handle in a shared location, allowing the second module to retrieve it itself. Yet another example is that the system passes the handle to the coordinator, which then distributes it to the second module.

[0043] In one specific implementation, the buffer manager returns the resource access handle to the first module, and the synchronization manager returns the synchronization signal handle to the first module. The first module can then pass the resource access handle and synchronization signal handle to the second module. If the first and second modules are on the same operating system, this can be achieved by sending file descriptors through inter-process communication mechanisms.

[0044] In this embodiment, the inherent association between the two handles is automatically maintained. The first module only needs to pass this pair of pre-associated handles to the second module, without needing to concern itself with the details of splicing the underlying primitives, thus completely eliminating the need for developers to manually splice the underlying primitives.

[0045] In this embodiment, a synchronous waiting mechanism ensures the correct timing of data access. A first synchronization signal handle in a ready state instructs the second module to access the shared buffer based on the resource access handle. The second module must wait for the synchronization signal handle to become ready before it can access the shared buffer based on the resource access handle.

[0046] In this embodiment, the second module is ensured to access the shared buffer only after the synchronization signal handle definitively indicates that the data is ready. This provides timing determinism at the system level, enabling developers to safely perform zero-copy operations and completely eliminate redundant memory copies.

[0047] According to an embodiment of this application, in response to a buffer request from a first module, a shared buffer is allocated, and a resource access handle for accessing the shared buffer is generated, along with a first synchronization signal handle bound to the current usage state of the shared buffer; wherein, the initial state of the first synchronization signal handle is "not ready". Subsequently, the resource access handle and the first synchronization signal handle are sent to a second module, wherein the first synchronization signal handle in the "ready" state is used to instruct the second module to perform access operations on the shared buffer based on the resource access handle. This application transforms the traditional development model, which requires manually concatenating multiple independent primitives, into a standardized process through a unified resource access handle and synchronization signal handle generation mechanism. Developers only need to follow a fixed data transfer process, without needing to concern themselves with the underlying implementation details such as shared memory mapping and cache refresh, significantly reducing development complexity and error rate. The waiting mechanism based on the synchronization signal handle ensures the deterministic timing of data access, effectively avoiding data race problems. At the same time, through zero-copy shared memory and asynchronous synchronization mechanisms, redundant memory copy operations are eliminated, significantly reducing CPU data transfer overhead and improving system throughput and processing efficiency. This application provides a unified synchronization primitive mechanism, enabling different modules to coordinate and operate efficiently, effectively eliminating synchronization barriers between systems. This design boasts good universality and scalability, applicable to various cross-module and cross-system data transmission scenarios, avoiding the complexity of maintaining multiple communication mechanisms. Ultimately, it achieves reusable processes and deterministic timing, providing an efficient and reliable solution for cross-module data interaction, significantly reducing development and maintenance costs while improving system performance.

[0048] In one optional embodiment of this application, the method further includes: generating a second synchronization signal handle corresponding to the asynchronous operation for accessing the shared buffer; wherein the initial state of the second synchronization signal handle is not ready; sending the second synchronization signal handle to the second module, wherein the second synchronization signal handle in the ready state is used together with the first synchronization signal handle in the ready state to instruct the second module to perform an access operation on the shared buffer based on the resource access handle.

[0049] Asynchronous operations refer to any non-blocking, background task that accesses a shared buffer. These operations may be initiated and executed by different modules. Asynchronous operations include, but are not limited to, operations of the first module itself and operations of other modules.

[0050] The second synchronization signal handle is created for each asynchronous operation whose completion status needs to be perceived by the second module. Each asynchronous operation corresponds to a dedicated synchronization signal handle. The initial state of these handles is not ready, and they are updated to ready by the system (synchronization manager) after the asynchronous operation to which they are bound is completed. In the system, there may be a first synchronization signal handle (identifying the completion of a specific operation of the first module) and one or more second synchronization signal handles (identifying the completion of other asynchronous operations).

[0051] The system (synchronization manager) instantiates a dedicated synchronization semaphore object for each asynchronous operation that needs to access the shared buffer. This object becomes the sole authoritative identifier of the operation's completion status.

[0052] In one specific implementation, when the system schedules an asynchronous task that will access a shared buffer, regardless of which module executes the task, the task initiator (which could be the first module or another coordinator) must declare a synchronization request to the synchronization manager: "Notify me when this operation is complete." The synchronization manager creates a new synchronization signal object (such as a new `dma_fence`) for this task, uniquely binds this object to the specific task instance, and returns its corresponding handle (such as a file descriptor `fd`). This handle serves as the sole credential for obtaining the completion status of this task.

[0053] The second synchronization signal handle is also sent to the second module. Multiple signals jointly control the access execution of the second module. This is the execution and activation stage of the multi-dependency synchronization mechanism. The second module (or its controlled hardware) must implement a mechanism that allows it to wait for all multiple synchronization signal handles to be ready before triggering the actual access operation.

[0054] By introducing a mechanism in the aforementioned synchronization framework that assigns multiple asynchronous operations to multiple synchronization signal handles and uses these handles to jointly control access, the problem of multi-source dependency synchronization in complex heterogeneous computing pipelines is successfully solved. This liberates the synchronization logic from cumbersome software coordination, transforming it into a deterministic mechanism managed uniformly by the system and executed efficiently by hardware. This provides a crucial technical foundation for realizing high-performance, low-latency, and highly reliable parallel data processing systems.

[0055] In one optional embodiment of this application, the method further includes: for a target asynchronous operation that accesses the shared buffer, in response to the completion of the target asynchronous operation, updating the state of the target synchronization signal handle corresponding to the target asynchronous operation from never ready to ready.

[0056] A target asynchronous operation refers to any specific task instance that needs to access a shared buffer and whose completion status needs to be known by other modules. For example, the first module writes data to the buffer. Another example is when modules other than the first and second modules process the data in the buffer.

[0057] The target synchronization signal handle is the synchronization signal object uniquely bound to the aforementioned target asynchronous operation. The target synchronization signal handle can be either the first synchronization signal handle or the second synchronization signal handle.

[0058] Upon completion of the asynchronous operation, the entity performing the target operation (such as a hardware accelerator or software thread) must send a completion notification to the system (synchronization manager). The system, acting as the state authority, verifies the notification and atomically toggles the state of the corresponding synchronization signal handle. The state of the target synchronization signal handle is then atomically updated to ready. The target synchronization signal handle's state is never updated from ready to ready.

[0059] The "Not Ready" state represents the initial and ongoing states, meaning that the bound target asynchronous operation has not yet been completed or is in progress, and any subsequent steps that depend on this operation must wait.

[0060] The "ready" state is the final state, which means that the bound target asynchronous operation has been successfully completed and the data or effects it produces are ready and safe to consume in the shared buffer.

[0061] By employing an authoritative, atomic, and reliable state update mechanism, discrete and asynchronous operation completion events in the physical world are transformed into unified and explicit synchronization signal states in the digital world. This not only solves the unreliability problem of state synchronization in traditional solutions but also provides the most crucial synchronization guarantee for building high-performance, highly deterministic, and scalable heterogeneous computing systems.

[0062] In one optional embodiment of this application, the second module's access to the shared buffer is controlled by a latch attribute; the latch attribute is bound to the target synchronization signal handle and is used to indicate the completion status of the target synchronization signal handle. It also includes updating the state of the latch attribute when a change in the state of the target synchronization signal handle is detected.

[0063] The latch attribute is a synchronization control interface provided by the system kernel or hardware components to establish a mandatory wait point on critical operation paths. It receives a synchronization signal handle as input and ensures that the operation must wait for the synchronization signal to indicate that the relevant operation has been completed before the action it controls is executed.

[0064] Each latch attribute is associated with a specific access operation, serving as a precondition checkpoint for that operation. Binding refers to establishing a configuration association between a latch attribute and a target synchronization handle. Technically, this typically involves setting the target synchronization handle (such as a file descriptor of a `sync_file`) to the value of the latch attribute. Once binding is complete, the "on / off" state of the latch attribute is determined by the "ready / not ready" state of the target synchronization handle.

[0065] When the system detects a change in the state of the target synchronization signal handle, it updates the state of the latch attribute. The value of the synchronization signal handle is assigned to the latch attribute. For example, the synchronization signal handle (sync_file fd) is assigned to the latch attribute (IN_FENCE_FD) of the display layer (Plane), thus embedding the synchronization dependency into the display submission process, forming a fixed synchronization latch mechanism.

[0066] The second module automatically and enforces waiting for synchronization conditions to be met on the critical path. This waiting is not something manually implemented by the application developer, but rather a behavior built into the kernel. For example, the kernel automatically waits for the synchronization signal pointed to by the latch attribute (IN_FENCE_FD) to complete during the atomic commit process, using this as the sole waiting point before scanning the output screen, ensuring that the display only starts after all pre-rendering tasks have finished.

[0067] First, the access standard for synchronization signals was unified, forcing all modules to inject synchronization dependencies through a unified interface (such as the IN_FENCE_FD attribute), fundamentally eliminating compatibility differences and fragmentation issues between different implementations, and ensuring stable compatibility across modules and projects.

[0068] Secondly, it solidifies key timing control points, transforming the logic of decentralized management of synchronization waiting points from the application layer into a single mandatory checkpoint implemented at the system kernel layer and hardware submission entry point. This transformation ensures that the timing of the entire pipeline from data production to consumption is strictly determined, completely eliminating the risk of screen tearing and incomplete data access.

[0069] Finally, a clear diagnostic interface is provided, and the standardized synchronization mechanism offers clear problem location points for system debugging. Developers can perform centralized checks on fixed synchronization access points (such as IN_FENCE_FD), significantly improving diagnostic efficiency and system maintainability.

[0070] In one alternative embodiment of this application, the asynchronous operation includes writing data to a shared buffer.

[0071] One of the most core and fundamental categories of asynchronous operations is writing data to a shared buffer. This is a producer behavior characterized by storing external data sources or processing results in a specific area of ​​the shared buffer. This operation is "asynchronous," meaning its execution is time-independent and does not block subsequent processes of the request initiator (such as the first module or coordinator). After the operation is complete, the data in the buffer is updated, becoming the input for subsequent operations.

[0072] Each write operation (producer) independently declares its completion via its own synchronization semaphore. Consumers simply wait for all relevant signals to know precisely that all the required data is ready. Producers and consumers do not need to know each other's existence or state; they communicate indirectly through shared buffers and synchronization semaphore handles, achieving a high degree of decoupling. Encapsulating each data write operation as an independent, waitable synchronization event allows downstream consumers to wait for all necessary data production to complete in a declarative, efficient, and reliable manner. This provides crucial synchronization primitives for building high-performance, highly reliable heterogeneous data processing systems, especially in computer vision, graphics rendering, and multimedia processing.

[0073] In one optional embodiment of this application, the method may further include: merging multiple synchronization signal handles corresponding to the shared buffer into a single synchronization signal handle; wherein the multiple synchronization signal handles include a first synchronization signal handle and at least one second synchronization signal handle, and the single synchronization signal handle is updated to be ready when the states of the multiple synchronization signal handles are all updated to be ready. Correspondingly, the second synchronization signal handle is provided to the second module, wherein the second synchronization signal handle in the ready state, together with the first synchronization signal handle in the ready state, is used to instruct the second module to perform an access operation on the shared buffer based on the resource access handle, including: providing the single synchronization signal handle to the second module, wherein the single synchronization signal handle in the ready state is used to instruct the second module to perform an access operation on the shared buffer based on the resource access handle.

[0074] Multiple synchronization signal handles refer to the set of all synchronization signal handles associated with the same shared buffer that need to be waited for simultaneously by the second module. Multiple synchronization signal handles include at least: a first synchronization signal handle and at least one second synchronization signal handle.

[0075] The system (synchronization manager) receives multiple synchronization signal handles as input and dynamically creates a new, logically higher-level, single synchronization signal handle. This new handle is called a merged handle or a synchronization fence. Its special feature lies in its state logic: it is an AND gate. Its state is automatically and atomically updated to ready only when the states of all input handles have become ready.

[0076] Before merging, multiple synchronization signal handles (first and second) need to be provided to the second module, which then handles the logic for waiting for all signals. After merging, only a single merged synchronization signal handle needs to be provided to the second module. The second module's management and waiting time has been simplified from handling multiple signals to waiting for only one signal.

[0077] For example, the synchronization manager provides unified services for creating, merging, notifying, and waiting for synchronization signals. The specific implementation includes: receiving multiple synchronization signal handles as input, creating a `dma_fence_array` object (triggered when all input fences are complete), wrapping the `dma_fence_array` into a new `sync_file` object, and returning the newly generated single synchronization file descriptor.

[0078] By employing a multi-dependency merging mechanism, multiple synchronization signal handles are aggregated into a single synchronization signal handle with all completion semantics, thus transforming the process from multi-way waiting to single-point waiting. This mechanism ensures that the consumer only continues execution after all preceding dependencies have truly completed, fundamentally eliminating timing uncertainty.

[0079] This application significantly reduces the implementation complexity of synchronization logic, simplifying the complex operation of manually managing multiple synchronization signal handles into a standardized process of waiting for a single merged handle. Simultaneously, by avoiding resource waste during idle waiting and CPU occupancy issues during busy waiting, it significantly improves system resource utilization efficiency.

[0080] This multi-dependency merging mechanism effectively solves the synchronization and coordination problem in multi-producer scenarios, provides a simple and reliable synchronization solution for complex data processing pipelines, and becomes a key technical foundation for building efficient parallel processing systems.

[0081] In one optional embodiment of this application, after the second module performs the access operation, it may further include: obtaining an output synchronization signal handle that identifies the completion status of the access operation; and performing a recycling operation or a reuse operation on the shared buffer if the completion status is "completed".

[0082] The completion status of an access operation refers to the state in which all hardware actions of a specific read (or process) operation initiated by the second module for the shared buffer have been completed and all effects of the operation have been achieved.

[0083] The output synchronization signal handle is a synchronization signal handle generated by the second module after completing data access, used to explicitly indicate that its use of the shared buffer has been completely completed.

[0084] For example, the synchronization file descriptor (i.e., the output synchronization signal handle) obtained from the OUT_FENCE attribute of the display controller (Cathode Ray Tube Controller, CRTC) indicates that the display scan output has been completed. This forms a symmetrical design with the input synchronization signal handle (such as IN_FENCE_FD), representing the synchronization events for the start and end of the operation, respectively.

[0085] The completion status of the access operation indicates that the second module's actual use of the shared buffer has been completely completed, and the data is no longer needed by any hardware or software components.

[0086] When the second module initiates the access operation, an output synchronization signal handle is created and associated synchronously. This output synchronization signal handle will be triggered after the consumer operation is completed.

[0087] For example, when initiating display scan output, the output synchronization signal handle is obtained from the OUT_FENCE attribute of the display controller. This handle will be automatically triggered after the frame scan is completed. By waiting for the output synchronization signal to become ready, the shared buffer can be safely reclaimed to ensure its use is complete. For example, the buffer manager waits for the output synchronization signal handle to become complete before reclaiming the corresponding shared buffer to the free pool or marking it as reusable.

[0088] The reclamation operation refers to the process of completely releasing all system resources occupied by a shared buffer. This includes: unmapping all modules from mapping and attaching to the buffer, releasing the physical memory pages it occupies, and destroying the corresponding scattering and aggregation lists, resource access handles, and related metadata. After reclamation, the buffer object no longer exists, and its resources can be used by the system for any other purpose.

[0089] Reuse refers to resetting a consumed shared buffer to its initial available state within the same data processing context or pipeline, and then placing it back into the idle resource pool, waiting to be populated with data again by the same producer or another producer. Reuse does not release the underlying physical memory; instead, it resets its management state (such as clearing old synchronization bindings), thereby achieving buffer recycling with zero allocation overhead.

[0090] By introducing an output synchronization signal mechanism, this application establishes a precise synchronization control system for the lifecycle management of the shared buffer. This mechanism, in conjunction with the aforementioned input synchronization mechanism, forms a complete timing control closed loop, jointly constructing an end-to-end deterministic guarantee framework.

[0091] Specifically, the output synchronization signal handle provides precise status indicators that accurately reflect when the buffer is finished. This ensures that the buffer is only reclaimed after all consumption operations have truly completed, fundamentally avoiding data conflicts and resource waste. This mechanism achieves safe buffer reclamation and efficient reuse, significantly reducing memory allocation overhead and improving overall system throughput.

[0092] At the same time, this mechanism provides a standardized framework for buffer lifecycle management. All modules follow a unified recycling specification, achieving an end-to-end predictable, reusable, and locatable management model.

[0093] In one optional embodiment of this application, the process of allocating a shared buffer includes: performing an export process for the shared buffer; wherein the export process includes cache consistency maintenance operations.

[0094] The export process refers to the process of packaging memory into a shareable object. When the system responds to a request to allocate a block of physical memory, it needs to export it as a globally recognizable object within the system that can be passed across modules / devices (such as dma_buf). The export process generates a resource access handle, marking that the buffer has officially entered a shareable state. At this point, the CPU may have already initialized the buffer or written metadata to it.

[0095] Cache consistency maintenance operations are low-level operations that ensure the consistency of cached data between the CPU and devices, resolving data visibility issues and handling hardware-level data synchronization. However, they do not represent the completion of the operation logic. Examples include the `begin_cpu_access` / `end_cpu_access` interface calls or the `DMA_BUF_IOCTL_SYNC` instruction.

[0096] The operation completion synchronization semantics are the business logic meaning of "asynchronous operation has been completed" carried by the synchronization signal handle. It is responsible for data synchronization at the hardware level, but does not mean that the operation logic is complete. For example, the dma-fence object encapsulated by sync_file indicates that the GPU rendering task has been completed.

[0097] In related technologies, developers often mistakenly equate cache synchronization completion with operation completion. This application enforces the separation of these two distinct concepts through architectural design: cache consistency is automatically handled by the cache manager at the underlying level, while the operation completion status is explicitly indicated by the synchronization manager through synchronization signal handles.

[0098] By solidifying and embedding cache consistency maintenance operations into the essential system-controlled export process, driver developers cannot overlook this critical operation. This significantly improves the robustness of the driver code and the reliability of the entire system, reducing systemic failures caused by cache inconsistency.

[0099] In one alternative embodiment of this application, the method prior to the first access operation further includes: performing an attach procedure for the shared buffer; wherein the attach procedure includes a cache consistency maintenance operation.

[0100] The attach process refers to the process of establishing a connection between a device and a shared buffer. When a device driver (such as a display driver or GPU driver) is ready to use an exported shared buffer for the first time, it needs to perform an "attach" operation for that device. This creates an access context for the specific device, recording device-specific attributes (such as the IOMMU field). At the time of the initial attach, the buffer may already contain data written by the CPU.

[0101] By solidifying and embedding cache consistency maintenance operations into the essential, system-controlled attachment process, driver developers cannot overlook this critical operation. This significantly improves the robustness of the driver code and the reliability of the entire system, reducing systemic failures caused by cache inconsistency.

[0102] In one optional embodiment of this application, the access operation includes: performing a mapping process for the shared buffer; wherein the mapping process includes a cache consistency maintenance operation.

[0103] The mapping process refers to the process of establishing address mappings that are accessible to a device. For example, the IOMMU (Import / Output Memory Management Unit) page table is created during mapping. Mapping is performed to prepare for a specific DMA transfer or device read. This operation calculates and establishes the required input / output virtual addresses for the device access and returns them to the driver. The mapping operation explicitly knows the direction of the access.

[0104] By solidifying and embedding cache consistency maintenance operations into the mandatory system-controlled mapping process, driver developers cannot overlook this critical operation. This significantly improves the robustness of the driver code and the reliability of the entire system, reducing systemic failures caused by cache inconsistency.

[0105] For example, the calls to begin / end CPU access or DMA_BUF_IOCTL_SYNC (Direct Memory Access Buffer Input / Output Control Synchronization Command) are embedded in the buffer manager's export / attach / map process, only handling CPU... Device cache semantics; synchronization is explicitly handled by the synchronization manager's fence system. Specifically, the buffer manager automatically calls `begin_cpu_access` when mapping a shared buffer and `end_cpu_access` when unmapping or committing. The synchronization manager independently manages DMA-fence objects to identify operation completion. Both are exposed to developers through different interfaces, with clear boundaries.

[0106] This application employs an architectural design that forcibly separates the two core concerns of cache consistency maintenance and operation completion synchronization. Cache consistency maintenance operations are embedded within the standard buffer management process, transparent to developers and effectively avoiding potential errors from manual invocation. This design clearly defines the boundaries between the two functions and establishes a fixed entry point, fundamentally eliminating the possibility of conceptual confusion, significantly reducing the risk of data errors due to misuse, and greatly improving system stability. This separation of responsibilities mechanism at the architectural level provides a reliable guarantee for data consistency, forming a crucial technical foundation for building a stable and reliable data sharing system.

[0107] In one optional embodiment of this application, the step of allocating a shared buffer includes creating a scattering aggregation list and caching the scattering aggregation list; it may also include returning the cached scattering aggregation list when other modules besides the first module request access to the shared buffer.

[0108] A scatter-gather list (sg_table) is a kernel data structure used to describe the scattering distribution of physical memory pages in the physical address space. When a logically contiguous buffer may consist of multiple physically non-contiguous pages, sg_table records the addresses and lengths of these physical pages.

[0109] For example, after allocating a shared buffer, the buffer manager constructs an sg_table to describe the physical page distribution of that shared buffer.

[0110] The created scattering cluster list is stored in memory for subsequent queries and reuse, avoiding repeated time-consuming build operations.

[0111] Other modules refer to multiple consumer modules that need to access the same shared buffer, excluding the first module. For example, when multiple devices (such as display controllers and video encoders) request access to the same shared buffer, it is a scenario that triggers sg_table reuse.

[0112] The sg_table created by the buffer manager when allocating buffers serves as metadata for the physical layout of the buffers. It is cached for reuse by other modules when accessing the same buffer, thus avoiding the need to repeatedly build the same sg_table for each device.

[0113] In traditional solutions, each device driver independently constructs an sg_table when accessing the same buffer, leading to redundant computation and IOMMU configuration overhead. This application optimizes the redundant computation of each device into shared metadata for each buffer through centralized sg_table cache management.

[0114] For example, after allocating a shared buffer and building an initial sg_table, the buffer manager caches it with the key (dma_buf, device_id (device identifier)). When a new device request is attached to the same shared buffer, the buffer manager first queries the cache. If a compatible sg_table is found, a cached copy is returned directly; otherwise, a new one is created and cached. This avoids repeated calls to time-consuming mapping operations.

[0115] This application optimizes the repetitive computation overhead, which originally increased linearly with the number of devices, into a constant cache lookup overhead by implementing a scatter-gathering table caching and deduplication strategy, significantly reducing CPU load. This mechanism effectively suppresses frequent configuration jitter of the input / output memory management unit, ensuring system performance stability under high load, especially meeting the stringent requirements of real-time multimedia processing. By avoiding redundant mapping operations, system throughput is improved, enabling the handling of more concurrent tasks under the same hardware conditions. This ingenious design based on metadata reuse solves the performance bottleneck of shared buffers across multiple devices, effectively complementing the infrastructure and jointly constructing a high-performance, low-overhead data sharing solution.

[0116] In one optional embodiment of this application, the first module is a decoding module, used to write decoded video frame data into a shared buffer, and the second module is a display module, used to read video frame data from the shared buffer and render it.

[0117] This is a specific and important example of a general data sharing and synchronization method in the field of video processing. The abstract first and second modules are concretized into two core entities in the video processing pipeline, which have a strict production-consumption time sequence: the decoding module and the display module.

[0118] The decoding module (a specific implementation of the first module) refers to the hardware unit or software component responsible for restoring compressed video data to its original pixel data. Its core responsibility is to write the decoded video frame data to the shared buffer. This is a producer role.

[0119] The display module (a specific implementation of the second module) refers to the hardware unit and its driver responsible for converting raw pixel data into display signals and outputting them to the screen. Examples include the display controller (DC), the display engine of a graphics processing unit (GPU), or a separate display processing chip. Its core responsibility is to read video frame data from a shared buffer and render it. This is a consumer role.

[0120] The decoded video frame data is the specific content stored in the shared buffer for this particular scenario. Writing is the production action of the decoding module, and reading is the consumption action of the display module. The rendering output further clarifies the purpose of reading. Finally, it is presented on the screen, which requires extremely high real-time performance and timing determinism.

[0121] For example, the decoding module completes the decoding of one frame (let's say frame N), writing the YUV (YUV color encoding model) data into a shared buffer. The decoding module notifies the system via a first synchronization signal handle (e.g., Sync_Decode_N): "Frame N data is ready." Before the time to display frame N arrives, the display module checks the state of Sync_Decode_N. Once Sync_Decode_N becomes "ready," the display module immediately reads the data from the shared buffer and begins rendering the output (scanning) to the screen.

[0122] The decoding module writes directly to the shared buffer, and the display module reads directly from the same buffer, completely eliminating the need for frame data to be copied back and forth between memory. This significantly reduces memory bandwidth usage and improves energy efficiency, which is key to smooth playback of high-resolution, high-bitrate videos.

[0123] The synchronization signal mechanism enables the display module to accurately sense the decoding completion time of each frame. Even if the decoding time fluctuates (such as I-frames in complex scenes), the display module can adaptively wait, avoiding frame drops or stuttering due to data not being ready. Combined with double / triple buffering, the utilization rate of the decoder can be maximized, maintaining a stable output frame rate.

[0124] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0125] Reference Figure 2This illustration shows a structural block diagram of another embodiment of the data sharing and synchronization system 200 based on dual-manager collaboration provided in this application, which may specifically include: Buffer manager 201 is used to allocate a shared buffer in response to a buffer request from the first module, generate a resource access handle for accessing the shared buffer, and then provide the resource access handle to the second module. Synchronization manager 202 is used to generate a first synchronization signal handle bound to the current usage state of the shared buffer, and then provide the first synchronization signal handle to the second module; wherein the initial state of the first synchronization signal handle is in an unready state; In this module, when the state of the first synchronization signal handle is ready, the second module performs access operations on the shared buffer based on the resource access handle.

[0126] Optionally, the sync manager is also used for: For asynchronous operations that access the shared buffer, a second synchronization signal handle corresponding to the asynchronous operation is generated; wherein, the initial state of the second synchronization signal handle is in an unready state; The second synchronization signal handle is sent to the second module, wherein the second synchronization signal handle in the ready state is used together with the first synchronization signal handle in the ready state to instruct the second module to perform an access operation on the shared buffer based on the resource access handle.

[0127] Optionally, the sync manager is also used for: For a target asynchronous operation that accesses the shared buffer, in response to the completion of the target asynchronous operation, the state of the target synchronization signal handle corresponding to the target asynchronous operation is updated from not ready to ready.

[0128] Optionally, the second module's access to the shared buffer is controlled by a latch attribute; the latch attribute is bound to the target synchronization signal handle and is used to indicate the completion status of the target synchronization signal handle; the synchronization manager is also used for: When a change in the state of the target synchronization signal handle is detected, update the state of the latch properties.

[0129] Optionally, the sync manager is also used for: Multiple synchronization signal handles corresponding to the shared buffer are merged into a single synchronization signal handle; wherein, the multiple synchronization signal handles include a first synchronization signal handle and at least one second synchronization signal handle, and when the status of the multiple synchronization signal handles is updated to ready, the single synchronization signal handle is updated to ready. A single synchronization signal handle is provided to the second module, wherein the single synchronization signal handle in the ready state is used to instruct the second module to access the shared buffer based on the resource access handle.

[0130] Optionally, the buffer manager is also used for: After the second module performs the access operation, obtain the handle of the output synchronization signal that indicates the completion status of the access operation; When the completion status is "completed", perform a recycling or reuse operation on the shared buffer.

[0131] Optionally, the buffer manager is specifically used for: Perform an export procedure for the shared buffer; the export procedure includes cache consistency maintenance operations.

[0132] Optionally, the buffer manager is also used for: Before the first access operation, an attach procedure is performed for the shared buffer; the attach procedure includes cache consistency maintenance operations.

[0133] Optionally, the buffer manager is also used for: Perform a mapping process for the shared buffer; the mapping process includes cache consistency maintenance operations.

[0134] Optionally, the buffer manager is specifically used for: Create a list of scattering clusters and cache the list of scattering clusters; When other modules besides the first module request access to the shared buffer, a cached list of scatter clusters is returned.

[0135] To enable those skilled in the art to better understand this application, the following specific examples illustrate a data sharing and synchronization system based on dual-manager collaboration.

[0136] This application proposes a data sharing and synchronization system based on dual-manager collaboration. The system comprises two core components: a buffer manager (BufMgr) and a synchronization manager (SyncManager, SyncMgr), which together provide efficient and reliable data sharing and synchronization services for upper-layer data producers (first module) and data consumers (second module).

[0137] The BufMgr, a kernel module, is responsible for the unified management of shared memory buffers across components. It allocates and exports buffers to producers through standard interfaces (such as BUFMGR_IOCTL_ALLOC_AND_EXPORT): a unified backend allocates physical memory on a page-by-page basis and maintains the page structure, then constructs a scattering aggregation list (sg_table), finally encapsulating it into a standard DMA-BUF object and returning the corresponding file descriptor. This descriptor can be passed and imported between processes or drivers. BufMgr also maintains buffer attachment information and mapping state, and implements safe release and reuse of buffers through a reference counting mechanism.

[0138] The SyncMgr, as a kernel character device, provides a unified mechanism for managing asynchronous synchronization primitives (fences). It supports the creation, merging, notification, and waiting of synchronization signals through a set of ioctl interfaces (such as SYNCMGR_IOCTL_CREATE_FENCE and SYNCMGR_IOCTL_MERGE_FENCES). This mechanism, based on the Linux kernel's sync_file and dma_fence implementations, can merge multiple synchronization events into a single synchronization object with "all completed" semantics, greatly simplifying synchronization processing in multi-dependency scenarios. Developers do not need to manually handle the underlying event notification or polling logic.

[0139] The aforementioned dual managers constitute the system's basic service framework. Data producers (such as video capture drivers and decoding threads) and consumers (such as display engines and audio processing units) achieve efficient data exchange and timing synchronization by calling the standardized interfaces provided by both. This architecture effectively achieves loose coupling and parallel processing between modules, improving the system's maintainability and overall performance.

[0140] The data processing flow is described below with reference to a typical embodiment. This embodiment describes the process from video frame generation to display, and the interaction of different modules is explained from the perspective of data flow in each step.

[0141] 1. Buffer allocation.

[0142] Producers (such as video decoders) initiate buffer allocation requests to the buffer manager (BufMgr). For example, they call `ioctl(bufmgr_fd, ALLOC_AND_EXPORT, ...)`. BufMgr handles subsequent processing: a unified backend allocates physical memory on a page-by-page basis, constructs a scattering aggregation list (sg_table), exports it as a dma-buf object, and finally returns the corresponding file descriptor to the producer. The producer can then map this buffer to its own user space using mmap (Memory Map) to gain direct read and write permissions.

[0143] 2. Data writing.

[0144] The producer writes data to the allocated shared buffer. For example, the decoder writes the decoded YUV (YUV color encoding model) data to memory, or the hardware writes it via DMA (Direct Memory Access). During this process, the buffer is exclusively used by the producer, with no concurrent access conflicts. After the write is complete, the buffer contains fully usable data.

[0145] 3. Synchronization signal creation and transmission.

[0146] Once the data is ready, the producer calls the synchronization manager (SyncMgr) to create a synchronization signal. For example, calling ioctl(syncmgr_fd, CREATE_FENCE, ...) returns a fence file descriptor with an initial state of "unsignaled". The producer then passes both the resource access handle and the fence handle to the consumer (such as the display module). If both parties are on the same system, the file descriptor can be passed via inter-process communication.

[0147] 4. Synchronous waiting for ready.

[0148] Before accessing data, consumers must wait for a synchronization signal to be ready. For example, the display module calls `ioctl(syncmgr_fd, WAIT_FENCE, fence_fd)` to enter a waiting state. `SyncMgr` monitors events associated with the fence (such as decoding completion). Once the producer notifies of completion via `ioctl(syncmgr_fd, NOTIFY_FENCE, fence_fd)`, `SyncMgr` updates the fence status to "signaled" and wakes up the consumer. This process eliminates the need for polling, significantly improving parallel efficiency.

[0149] 5. Data reading and usage.

[0150] After synchronization is complete, the consumer can safely read the buffer data. For example, the display module associates dma-buf with the display device, directly reading pixel data and sending it to video memory without memory copying, significantly reducing latency and CPU overhead. Before submitting for display, the synchronization signal can be set to the IN_FENCE_FD attribute of the display layer via SyncMgr to ensure that display operations are only performed after the data is ready.

[0151] 6. Buffer release and reuse.

[0152] After data usage is complete, the consumer releases the buffer via BufMgr. For example, by calling ioctl(bufmgr_fd, FREE, buf_handle) or closing the corresponding file descriptor, BufMgr safely reclaims the buffer for reuse. For continuous data processing scenarios, multiple buffers can be used in a cyclical manner, combined with the fence mechanism to achieve efficient parallel pipelined processing between producers and consumers.

[0153] This application, through the collaboration of BufMgr and SyncMgr, separates yet unifies shared memory management and synchronization control, providing an efficient and reliable solution for cross-module data exchange. This design shields the complex details of underlying memory mapping, cache consistency, and multi-system interaction, greatly reducing development complexity and improving system maintainability and performance.

[0154] like Figure 3 The diagram shown is a data sharing and synchronization system based on dual-manager collaboration, which mainly includes the application layer, dynamic libraries, and kernel mode.

[0155] 1. allocate memory and create sync objs.

[0156] Application initialization steps. The Application (application layer / main control program) calls the user-space library interfaces of BufMgr (buffer manager) and SyncMgr (synchronization manager).

[0157] Specifically, before starting the pipeline, the Application first allocates a shared buffer (BufObj) through the buffer manager library. Then, it creates all three synchronization objects (SyncObj1, SyncObj2, SyncObj3) required for this process through the sync manager library.

[0158] 2. Submit CSI task (Submit camera serial interface task), Submit ISP task (Submit image signal processor task), and Submit Display task (Submit display task).

[0159] Task submission and resource transfer. The Application passes resource access handles and corresponding synchronization signal handles to each processing unit.

[0160] The application passes BufObj and SyncObj1 to the CSI Library (Camera Serial Interface Library), BufObj, SyncObj1, and SyncObj2 to the ISP Library (Image Signal Processor Library), and BufObj, SyncObj2, and SyncObj3 to the DISPLAY Library. It then returns the resource access handle and synchronization signal handle to the first module, which in turn provides them to the second module. The resource access handle (BufObj) and synchronization signal handle (SyncObj) are passed together in a bound manner.

[0161] 3. Submit from each library to the corresponding driver (e.g., CSI Library -> CSI driver).

[0162] Hardware task submission. User-space libraries submit tasks and associated synchronization signals to kernel-space device drivers.

[0163] The CSI library submits the task, buffer, and SyncObj1 to the CSI driver. The driver begins performing hardware operations (such as acquiring a frame of image into the buffer). The ISP library submits the task, buffer, and SyncObj1 and SyncObj2 to the ISP driver. The DISPLAY library submits the task, buffer, and SyncObj2 and SyncObj3 to the CSI driver. The driver begins performing hardware operations.

[0164] 4. Notify SyncObj1 / 2 (from the driver to Sync Manager).

[0165] Hardware operation completed notification. This is the key to the entire synchronization mechanism.

[0166] Once the CSI hardware completes the acquisition of one frame of data, the CSI driver calls the SyncMgr interface to notify SyncObj1 that it has completed. This action changes the status of SyncObj1 from "not ready" to "completed." This is essentially the "notification" service of the synchronization manager.

[0167] 5. wait SyncObj1 / 2 (from ISP Library / DISPLAY Library to Sync Manager).

[0168] The consumer waits for its dependencies to be ready. The consumer module waits for the prerequisite tasks of its dependencies to complete.

[0169] Before executing its own tasks, the ISP Library must wait for SyncObj1 to complete (i.e., wait for the CSI task to complete). It achieves this blocking or asynchronous waiting by calling the SyncMgr's "wait" service. Once SyncObj1 is notified of its completion, the ISP Library is awakened and begins processing the data in the buffer.

[0170] 6. Wait SyncObj3 (the application's final wait).

[0171] The application waits for the entire pipeline to complete.

[0172] The application knows that the entire processing pipeline has been completed by waiting for the completion of the last synchronization object, SyncObj3 (the explicit task). At this point, it can safely reclaim the buffer or start the next round of processing.

[0173] This application establishes a basic paradigm for cross-module data sharing and synchronization, which has the following outstanding advantages: 1. Significantly improved real-time performance Based on a zero-copy shared memory mechanism and asynchronous latch technology, this architecture achieves decoupled parallelism between the production and consumption processes. Specifically, while the producer transmits data, the consumer can pre-acquire a buffer and enter a standby state, forming a pipeline operation mode of "production-transmission-consumption". This design eliminates the serial latency problem in traditional solutions, which requires waiting for complete transmission before notifying the receiver. Real-world testing shows that end-to-end latency is reduced by more than 60%, providing millisecond-level response capabilities for high frame rate audio and video, industrial real-time control, and other scenarios, effectively eliminating stuttering and latency accumulation.

[0174] 2. System throughput and energy efficiency optimization By eliminating redundant memory copies and invalid context switches, CPU resources are concentrated on business computation. The buffer manager uses physical page-level memory allocation and, combined with a scatter-gather table, directly supports DMA transfers, achieving a highly simplified data path. The synchronization manager replaces polling with asynchronous notification, further reducing CPU overhead. In actual video processing scenarios, the problem of traditional solutions requiring 2-3 copies of data per frame is completely solved, CPU data handling overhead is reduced by more than 70%, and the system's data throughput under the same hardware conditions is doubled.

[0175] 3. Breakthrough in cross-system collaboration capabilities The synchronization manager provides a unified synchronization primitive abstraction layer across operating systems, enabling heterogeneous system modules to work collaboratively within the same timing architecture. For complex scenarios such as in-vehicle heterogeneous computing and edge device collaboration, this application eliminates synchronization barriers between systems through standardized signal interfaces. Specifically, through latch state synchronization and timeout control mechanisms, cross-system communication latency is reduced by more than 40% while ensuring data consistency, significantly improving the reliability of data exchange in distributed systems.

[0176] 4. Development and operation efficiency doubled The dual-manager architecture encapsulates complex low-level primitive operations into standardized interfaces, providing high-level abstractions such as "allocating buffers" and "waiting for synchronization." This design frees developers from worrying about low-level details like shared memory mapping and cache consistency, reducing the amount of code in the communication module by 80%. Simultaneously, the architecture's built-in unified error handling and status monitoring mechanisms improve system debugging efficiency by 3 times, significantly reducing overall lifecycle maintenance costs. Real-world testing shows that the integration cycle for new features has been shortened from an average of 3 person-months to 1 person-week.

[0177] 5. Architectural universality and evolvability This application employs a layered abstraction design, supporting both high-volume data transmission (such as audio and video streams) and lightweight interactions (such as control signaling) through a memory abstraction layer in the buffer manager and an event abstraction layer in the synchronization manager. When new hardware or business modules are introduced, only the manager adaptation layer needs to be implemented for rapid system integration. This design provides sustainable architectural support for technological evolution.

[0178] This application achieves generational improvements in five dimensions—performance, efficiency, collaboration, ease of use, and scalability—through systematic innovation, laying a solid technical foundation for next-generation distributed systems. Its core value lies in encapsulating complex underlying technologies into simple and reliable system-level services, enabling developers to focus on business logic innovation.

[0179] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0180] Figure 4 This is a structural block diagram illustrating an electronic device 700 for data sharing and synchronization according to an exemplary embodiment. For example, the electronic device 700 may be a vehicle-mounted computer, a computer, a digital broadcasting terminal, a messaging device, a game console, a medical device, a fitness device, etc.

[0181] Reference Figure 4The electronic device 700 may include one or more of the following components: a processing component 702, a memory 704, a power supply component 706, a multimedia component 708, an audio component 710, an input / output (I / O) interface 712, a sensor component 714, and a communication component 716.

[0182] Processing component 702 typically controls the overall operation of electronic device 700, such as operations associated with display, telephone calls, data communication, camera operation, and recording operations. Processing component 702 may include one or more processors 720 to execute instructions to complete all or part of the steps of the methods described above. Furthermore, processing component 702 may include one or more modules to facilitate interaction between processing component 702 and other components. For example, processing component 702 may include a multimedia module to facilitate interaction between multimedia component 708 and processing component 702.

[0183] Memory 704 is configured to store various types of data to support the operation of device 700. Examples of this data include instructions for any application or method operating on electronic device 700, contact data, phonebook data, messages, pictures, videos, etc. Memory 704 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk.

[0184] Power supply component 706 provides power to various components of electronic device 700. Power supply component 706 may include a power management system, one or more power supplies, and other components associated with generating, managing, and distributing power to electronic device 700.

[0185] Multimedia component 708 includes a screen that provides an output interface between the electronic device 700 and the user. In some embodiments, the screen may include a liquid crystal display (LCD) and a touch panel (TP). If the screen includes a touch panel, the screen may be implemented as a touchscreen to receive input signals from the user. The touch panel includes one or more touch sensors to sense touches, swipes, and gestures on the touch panel. The touch sensors may sense not only the boundaries of the touch or swipe action but also the duration and pressure associated with the touch or swipe operation. In some embodiments, multimedia component 708 includes a front-facing camera and / or a rear-facing camera. When the electronic device 700 is in an operating mode, such as a shooting mode or a video mode, the front-facing camera and / or the rear-facing camera may receive external multimedia data. Each front-facing camera and rear-facing camera may be a fixed optical lens system or have focal length and optical zoom capabilities.

[0186] Audio component 710 is configured to output and / or input audio signals. For example, audio component 710 includes a microphone (MIC) configured to receive external audio signals when electronic device 700 is in an operating mode, such as call mode, recording mode, and voice recognition mode. The received audio signals may be further stored in memory 704 or transmitted via communication component 716. In some embodiments, audio component 710 also includes a speaker for outputting audio signals.

[0187] I / O interface 712 provides an interface between processing component 702 and peripheral interface modules, such as keyboards, click wheels, buttons, etc. These buttons may include, but are not limited to, home buttons, volume buttons, power buttons, and lock buttons.

[0188] Sensor assembly 714 includes one or more sensors for providing state assessments of various aspects of electronic device 700. For example, sensor assembly 714 may detect the on / off state of device 700, the relative positioning of components such as the display and keypad of electronic device 700, changes in position of electronic device 700 or a component of electronic device 700, the presence or absence of user contact with electronic device 700, orientation or acceleration / deceleration of electronic device 700, and temperature changes of electronic device 700. Sensor assembly 714 may include a proximity sensor configured to detect the presence of nearby objects without any physical contact. Sensor assembly 714 may also include a light sensor, such as a CMOS or CCD image sensor, for use in imaging applications. In some embodiments, sensor assembly 714 may also include an accelerometer, gyroscope, magnetometer, pressure sensor, or temperature sensor.

[0189] Communication component 716 is configured to facilitate wired or wireless communication between electronic device 700 and other devices. Electronic device 700 can access wireless networks based on communication standards, such as WiFi, 2G, or 3G, or combinations thereof. In one exemplary embodiment, communication component 716 receives broadcast signals or broadcast-related information from an external broadcast management system via a broadcast channel. In one exemplary embodiment, communication component 716 also includes a near-field communication (NFC) module to facilitate short-range communication. For example, the NFC module may be implemented based on radio frequency identification (RFID) technology, Infrared Data Association (IrDA) technology, ultra-wideband (UWB) technology, Bluetooth (BT) technology, and other technologies.

[0190] In an exemplary embodiment, the electronic device 700 may be implemented by one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), controllers, microcontrollers, microprocessors, or other electronic components to perform the methods described above.

[0191] In an exemplary embodiment, a non-transitory computer-readable storage medium including instructions is also provided, such as a memory 704 including instructions, which can be executed by a processor 720 of an electronic device 700 to perform the above-described method. For example, the non-transitory computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device, etc.

[0192] A non-transitory computer-readable storage medium, when instructions in the storage medium are executed by a terminal's processor, enables the terminal to perform a data sharing and synchronization method, applied to a data sharing and synchronization system, the method comprising: In response to the buffer request from the first module, a shared buffer is allocated, and a resource access handle for accessing the shared buffer is generated, as well as a first synchronization signal handle bound to the current usage state of the shared buffer; wherein the initial state of the first synchronization signal handle is in an unready state. The resource access handle and the first synchronization signal handle are sent to the second module, wherein the first synchronization signal handle, which is in a ready state, is used to instruct the second module to perform an access operation on the shared buffer based on the resource access handle.

[0193] Optionally, the method further includes: For asynchronous operations that access the shared buffer, a second synchronization signal handle corresponding to the asynchronous operation is generated; wherein the initial state of the second synchronization signal handle is in an unready state; The second synchronization signal handle is sent to the second module, wherein the second synchronization signal handle in the ready state is used together with the first synchronization signal handle in the ready state to instruct the second module to perform an access operation on the shared buffer based on the resource access handle.

[0194] Optionally, the method further includes: For a target asynchronous operation that accesses the shared buffer, in response to the completion of the target asynchronous operation, the state of the target synchronization signal handle corresponding to the target asynchronous operation is updated from "not ready" to "ready".

[0195] Optionally, the second module's access to the shared buffer is controlled by a latch attribute; the latch attribute is bound to the target synchronization signal handle and is used to indicate the completion status of the target synchronization signal handle; the method further includes: When a change in the state of the target synchronization signal handle is detected, the state of the latch attribute is updated.

[0196] Optionally, the asynchronous operation includes writing data to the shared buffer.

[0197] Optionally, the method further includes: The multiple synchronization signal handles corresponding to the shared buffer are merged into a single synchronization signal handle; wherein the multiple synchronization signal handles include a first synchronization signal handle and at least one second synchronization signal handle, and when the status of the multiple synchronization signal handles is updated to the ready state, the single synchronization signal handle is updated to the ready state. The step of providing the second synchronization signal handle to the second module, wherein the second synchronization signal handle in a ready state is used together with the first synchronization signal handle in a ready state to instruct the second module to perform an access operation on the shared buffer based on the resource access handle, includes: The single synchronization signal handle is provided to the second module, wherein the single synchronization signal handle in the ready state is used to instruct the second module to access the shared buffer based on the resource access handle.

[0198] Optionally, after the second module performs the access operation, the following method is also included: Obtain the handle of the output synchronization signal that indicates the completion status of the access operation; If the completion status is "completed", a recycling operation or a reuse operation is performed on the shared buffer.

[0199] Optionally, the process of allocating the shared buffer includes: Execute an export procedure for the shared buffer; wherein the export procedure includes cache consistency maintenance operations.

[0200] Optionally, the method prior to the first access operation further includes: Execute an attach procedure for the shared buffer; wherein the attach procedure includes cache consistency maintenance operations.

[0201] Optionally, the access operation includes: Execute a mapping process for the shared buffer; wherein the mapping process includes cache consistency maintenance operations.

[0202] Optionally, the step of allocating the shared buffer includes; Create a scattering cluster list and cache the scattering cluster list; The method further includes: When other modules besides the first module request access to the shared buffer, a cached list of scattering clusters is returned.

[0203] Optionally, the first module is a decoding module, used to write decoded video frame data into the shared buffer, and the second module is a display module, used to read the video frame data from the shared buffer and render it.

[0204] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

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

[0206] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0207] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0208] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0210] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only 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 terminal device 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 terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0211] The foregoing has provided a detailed description of a data sharing and synchronization method, a dual-manager-based data sharing and synchronization system, an electronic device, and a readable storage medium provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A data sharing and synchronization method, characterized in that, The method, applied to data sharing and synchronization systems, includes: In response to the buffer request from the first module, a shared buffer is allocated, and a resource access handle for accessing the shared buffer is generated, as well as a first synchronization signal handle bound to the current usage state of the shared buffer; wherein the initial state of the first synchronization signal handle is in an unready state. The resource access handle and the first synchronization signal handle are sent to the second module, wherein the first synchronization signal handle, which is in a ready state, is used to instruct the second module to perform an access operation on the shared buffer based on the resource access handle.

2. The method according to claim 1, characterized in that, The method further includes: For asynchronous operations that access the shared buffer, a second synchronization signal handle corresponding to the asynchronous operation is generated; wherein the initial state of the second synchronization signal handle is in an unready state; The second synchronization signal handle is sent to the second module, wherein the second synchronization signal handle in the ready state is used together with the first synchronization signal handle in the ready state to instruct the second module to perform an access operation on the shared buffer based on the resource access handle.

3. The method according to claim 1 or 2, characterized in that, The method further includes: For a target asynchronous operation that accesses the shared buffer, in response to the completion of the target asynchronous operation, the state of the target synchronization signal handle corresponding to the target asynchronous operation is updated from "not ready" to "ready".

4. The method according to claim 3, characterized in that, The second module's access to the shared buffer is controlled by a latch attribute; the latch attribute is bound to the target synchronization signal handle and is used to indicate the completion status of the target synchronization signal handle; The method further includes: When a change in the state of the target synchronization signal handle is detected, the state of the latch attribute is updated.

5. The method according to claim 2, characterized in that, The asynchronous operation includes writing data to the shared buffer.

6. The method according to claim 2, characterized in that, The method further includes: The multiple synchronization signal handles corresponding to the shared buffer are merged into a single synchronization signal handle; wherein the multiple synchronization signal handles include a first synchronization signal handle and at least one second synchronization signal handle, and when the status of the multiple synchronization signal handles is updated to the ready state, the single synchronization signal handle is updated to the ready state. The step of providing the second synchronization signal handle to the second module, wherein the second synchronization signal handle in a ready state is used together with the first synchronization signal handle in a ready state to instruct the second module to perform an access operation on the shared buffer based on the resource access handle, includes: The single synchronization signal handle is provided to the second module, wherein the single synchronization signal handle in the ready state is used to instruct the second module to access the shared buffer based on the resource access handle.

7. The method according to claim 1, characterized in that, After the second module performs the access operation, it also includes: Obtain the handle of the output synchronization signal that indicates the completion status of the access operation; If the completion status is "completed", a recycling operation or a reuse operation is performed on the shared buffer.

8. The method according to claim 1, characterized in that, The process of allocating the shared buffer includes: Execute an export procedure for the shared buffer; wherein the export procedure includes cache consistency maintenance operations.

9. The method according to claim 1, characterized in that, The method described prior to the first access operation also includes: Execute an attach procedure for the shared buffer; wherein the attach procedure includes cache consistency maintenance operations.

10. The method according to claim 1, characterized in that, The access operation includes: Execute a mapping process for the shared buffer; wherein the mapping process includes cache consistency maintenance operations.

11. The method according to claim 1, characterized in that, The step of allocating the shared buffer includes: Create a scattering cluster list and cache the scattering cluster list; The method further includes: When other modules besides the first module request access to the shared buffer, a cached list of scattering clusters is returned.

12. The method according to claim 1, characterized in that, The first module is a decoding module, used to write decoded video frame data into the shared buffer, and the second module is a display module, used to read the video frame data from the shared buffer and render it.

13. A data sharing and synchronization system based on dual-manager collaboration, characterized in that, include: A buffer manager is used to allocate a shared buffer in response to a buffer request from the first module, generate a resource access handle for accessing the shared buffer, and then provide the resource access handle to the second module. A synchronization manager is used to generate a first synchronization signal handle bound to the current usage state of the shared buffer, and then provide the first synchronization signal handle to the second module; wherein the initial state of the first synchronization signal handle is in an unready state; Specifically, when the state of the first synchronization signal handle is ready, the second module performs access operations on the shared buffer based on the resource access handle.

14. The system according to claim 13, characterized in that, The synchronization manager is also used for: For asynchronous operations that access the shared buffer, a second synchronization signal handle corresponding to the asynchronous operation is generated; wherein the initial state of the second synchronization signal handle is in an unready state; The second synchronization signal handle is sent to the second module, wherein the second synchronization signal handle in the ready state is used together with the first synchronization signal handle in the ready state to instruct the second module to perform an access operation on the shared buffer based on the resource access handle.

15. The system according to claim 13 or 14, characterized in that, The synchronization manager is also used for: For a target asynchronous operation that accesses the shared buffer, in response to the completion of the target asynchronous operation, the state of the target synchronization signal handle corresponding to the target asynchronous operation is updated from "not ready" to "ready".

16. The system according to claim 15, characterized in that, The second module's access to the shared buffer is controlled by a latch attribute; the latch attribute is bound to the target synchronization signal handle and is used to indicate the completion status of the target synchronization signal handle; the synchronization manager is further configured to: When a change in the state of the target synchronization signal handle is detected, the state of the latch attribute is updated.

17. The system according to claim 14, characterized in that, The synchronization manager is also used for: The multiple synchronization signal handles corresponding to the shared buffer are merged into a single synchronization signal handle; wherein the multiple synchronization signal handles include a first synchronization signal handle and at least one second synchronization signal handle, and when the status of the multiple synchronization signal handles is updated to the ready state, the single synchronization signal handle is updated to the ready state. The single synchronization signal handle is provided to the second module, wherein the single synchronization signal handle in the ready state is used to instruct the second module to access the shared buffer based on the resource access handle.

18. The system according to claim 13, characterized in that, The buffer manager is also used for: After the second module performs the access operation, it obtains the handle of the output synchronization signal that indicates the completion status of the access operation; If the completion status is "completed", a recycling operation or a reuse operation is performed on the shared buffer.

19. The system according to claim 13, characterized in that, The buffer manager is specifically used for: Execute an export procedure for the shared buffer; wherein the export procedure includes cache consistency maintenance operations.

20. The system according to claim 13, characterized in that, The buffer manager is also used for: Prior to the first access operation, an attach procedure is performed for the shared buffer; wherein the attach procedure includes a cache consistency maintenance operation.

21. The system according to claim 13, characterized in that, The buffer manager is also used for: Execute a mapping process for the shared buffer; wherein the mapping process includes cache consistency maintenance operations.

22. The system according to claim 13, characterized in that, The buffer manager is specifically used for: Create a scattering cluster list and cache the scattering cluster list; When other modules besides the first module request access to the shared buffer, a cached list of scattering clusters is returned.

23. An electronic device, characterized in that, It includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the data sharing and synchronization method as described in any one of claims 1-12.

24. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the data sharing and synchronization method as described in any one of claims 1-12.

Images