Safety shared memory communication

Abstract

To provide a method of safety shared memory communication between processes, a system therefor, and a non-temporary computer-readable medium.SOLUTION: In a method of shared memory communication, data structure for communication of data reference to data in a shared memory is generated and maintained. The data structure can be read and written by a transmitter, and includes a queue of data reference which can be only read by a receiver, a write index which indicates a write position in the queue and which can be read and written by the transmitter, a write index which can be read and written by the transmitter and can be only read by the receiver, and a read index which indicates a read position in the queue and which can be only read by the transmitter and which can be read and written by the receiver.SELECTED DRAWING: Figure 1A

Description

[Technical Field]

[0001]

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 567,620, filed March 20, 2024, which is incorporated herein by reference as if set forth in its entirety.

[0002] FIELD OF THE INVENTION

[0003] SUMMARY OF THE INVENTION The embodiments described herein are directed generally to inter-process communication, and more particularly to secure shared memory communication between processes. [Background technology]

[0003]

[0004] Description of Related Art

[0005] (queue)

[0006] A queue is a fundamental data structure in computer science and information technology for managing data in a first-in, first-out (FIFO) manner. Queues are used in many different areas, including computer programming, data processing, and communication systems. Traditional queues support the basic operations of enqueueing (adding an element to the end of the queue) and dequeueing (removing an element from the front of the queue).

[0004]

[0007] A queue generally comprises a linear data structure in which data elements are stored in a particular order. Each element in a queue is associated with a unique position in the queue. Generally, the front of the queue represents the read position (i.e., the position from which elements are read) and the back of the queue represents the write position (i.e., the position to which elements are written).

[0005]

[0008] (Lock-free queue)

[0009] Queues are sometimes used to exchange data between two or more threads of execution. In this case, the queue becomes a shared data structure that is subject to data races. A data race occurs when two or more threads access the same queue simultaneously, and at least one of these accesses modifies an element in the queue (for example, by enqueuing or dequeuing an element).

[0006]

[0010] Preventing data races in queues has traditionally been achieved by blocking algorithms, which prevent the queue from being modified or accessed by multiple threads of execution at the same time. Such blocking algorithms may employ mutual exclusion-like constructs, often called "mutexes." A mutex is a program object that prevents multiple threads from accessing the same shared resource at the same time.

[0007]

[0011] Lock-free algorithms are a more innovative and efficient approach than blocking algorithms. Lock-free algorithms eliminate the risk of deadlocks and corrupted mutexes. A deadlock is a situation in which one process shares the same resource with another process and effectively blocks the other process from accessing that resource, thereby preventing the other process from functioning. Lock-free algorithms offer several advantages over blocking algorithms, but at the expense of increased complexity.

[0008]

[0012] The key to the operation of lock-free algorithms for accessing queues is atomic operations such as compare-and-swap (CAS), which are operations that appear to occur instantly from the perspective of all threads accessing the queue. These atomic operations allow concurrent operation of the data structure underlying the queue.

[0009]

[0013] (Inter-process communication (IPC) via shared memory)

[0014] Operating systems typically have built-in mechanisms that allow data exchange between processes (Unix domain sockets, message queues, etc.). Shared memory is a widely adopted feature in almost all major operating systems, including Windows and operating systems based on the Portable Operating System Interface (POSIX). Shared memory is a state-of-the-art technology for efficiently sharing data between processes, facilitating optimal data exchange and resource utilization.

[0010]

[0015] The use of shared memory between processes allows multiple processes in an operating system to access and operate on the shared memory. The main advantage of shared memory as an inter-process communication (IPC) mechanism compared to other IPC mechanisms is that it eliminates the overhead associated with copying data to other memory spaces, reducing the load on the central processing unit (CPU). Therefore, shared memory is a higher-performance IPC channel than other options.

[0011]

[0016] However, shared memory also has drawbacks: in particular, it offers the possibility of data corruption by a single process, which can affect all other processes and require them to be restored to working order.

[0012]

[0017] (zero copy communication)

[0018] Zero-copy communication is a communication paradigm rooted in the principles of shared memory. The core concept of this communication paradigm is the creation of a shared memory region accessible by multiple processes. In this paradigm, a sender of data writes its payload to the shared memory region and then sends a data reference, such as a pointer or offset to this payload, to all intended recipients. Advantageously, the sender can share data by writing it only once and sending a data reference to the payload, hence the name "zero-copy communication." However, implementing zero-copy communication is a demanding task, as it must be able to handle issues such as failed processes without compromising the integrity of the entire system and the shared memory region.

[0013]

[0019] (Shared memory-based communication middleware)

[0020] There are many commercial and open source implementations of shared memory based communication systems. Below we will discuss some specific implementations.

[0014]

[0021] (Eclipse eCAL)

[0022] The enhanced Communication Abstraction Layer (eCAL) provided by the Eclipse Foundation in Brussels, Belgium, is middleware that transfers data using shared memory files. In Eclipse eCAL® version 5.9.0, the sender writes data to the shared memory file and the receiver reads the data from the shared memory file. Access to the shared memory file is protected by a mutex. In this method, messages are exchanged one at a time through the shared memory file. Eclipse eCAL does not support queuing. Therefore, the sender is blocked while the receiver is accessing the data, and vice versa.

[0015]

[0023] (Eclipse Zeno)

[0024] Zeno is a communications middleware written in the Rust programming language, also provided by the Eclipse Foundation. Eclipse Zeno (registered trademark) provides a publish-subscribe shared memory model specialized for zero-copy communication, leveraging the shared memory Rust crate. In Eclipse Zeno version 0.11.0, the sender initiates communication by creating a POSIX shared memory object and using a local allocator with a heap strategy. The receiver accesses this shared memory object according to a predefined naming convention and integrates with the Rust Tokio networking framework to obtain data offsets. Once data processing is complete, the receiver decrements the reference counter belonging to the transferred data. In particular, the sender is responsible for aggressive garbage collection during allocation so that memory used for previous data transfers can be reused.

[0016]

[0025] (Eclipse iceoryx)

[0026] Iceoryx, also provided by the Eclipse Foundation, transfers data using lock-free queues. Eclipse Iceoryx® supports zero-copy communication by using multiple buffers and transferring only data references to messages through queues. The messages themselves are stored in a separate shared memory. It is also possible to configure multiple shared memory areas for storing messages and set access rights to these shared memory areas. Only selected user groups can read and write messages stored in the shared memory. This method is described in U.S. Patent Application Publication No. 2022 / 374536 (published November 24, 2022). However, this approach only addresses the memory for storing exchanged messages. It does not consider the data structures in the shared memory used to pass data references to these messages.

[0017]

[0027] (multiple buffers)

[0028] Shared memory communication often uses multiple buffers, which allow the sender to write new messages while the receiver is still reading old messages, providing good decoupling between sender and receiver. Buffer usage is usually tracked by a reference counter, allowing the sender to allocate a free buffer when writing a new message. This strategy allows for zero-copy communication, assuming the sender writes data directly to the buffer and the reader reads data directly from the buffer without copying it to another memory location.

[0018]

[0029] (interference-free communication)

[0030] Interference-free is defined in the International Organization for Standardization (ISO) 26262 standard as "the absence of cascading failures between two or more elements that could lead to the violation of safety requirements." In the context of data communications, this means that a failure on one side of a communication channel does not cause a failure on the other side of the communication channel. For a communication channel based on shared memory, this means that the sender and receiver cannot block each other's execution or corrupt the other's memory.

[0019]

[0031] (Weaknesses of the cutting edge)

[0032] State-of-the-art shared memory-based IPC middleware cannot guarantee the interference-free operation required for secure data transfer between various safety-critical processes, due to one or more of the following weaknesses:

[0020]

[0033] (using mutexes or other locking mechanisms)

[0034] Many shared memory communication systems (e.g., Eclipse eCAL) use mutexes to handle multi-threaded access to exchanged messages or to control data used to coordinate data transfer between communicating entities. However, using mutexes to achieve temporal interference-free operation between communicating entities is difficult. A process (e.g., a software application) may be able to tolerate being blocked for short periods by other communicating entities. However, thread scheduling or crashes of other communicating entities can cause the process to be blocked for long periods or even enter deadlock. While there are mechanisms to mitigate this possibility, such as timeouts and detection of corrupted mutexes, each of these mechanisms has its drawbacks.

[0021]

[0035] (Use of an insecure mechanism to transfer ownership of a buffer)

[0036] Shared memory communication systems based on multi-buffer architectures must pass ownership of buffers between senders and receivers. A sender needs ownership of a free buffer to write a new message, and a receiver needs ownership of a written buffer to safely read a message. Buffer ownership is often passed by transferring a data reference to the memory buffer, such as a buffer index or pointer. This can be done using one of the IPC mechanisms provided by the operating system, or by using data structures that are also located in shared memory. For example, Eclipse Iceoryx uses a lock-free queue in shared memory to pass data references to messages between senders and receivers.

[0022]

[0037] If an operating system's IPC mechanism is used, it must meet the safety guarantees required for messages transferred between safety-critical processes. However, many middleware implementations use standard socket-based communication, which cannot provide such safety guarantees on most state-of-the-art operating systems.

[0023]

[0038] (Use of unprotected control data in shared memory)

[0039] When using a shared memory data structure to transfer buffer ownership, as in Eclipse Iceoryx, this data structure must be accessible to both the sender and the receiver. Therefore, this data structure is vulnerable to memory corruption and cannot achieve interference-free operation. If this data structure is corrupted by one of the communicating entities, interference-free operation is no longer valid, and corrupted memory failures (such as crashes) may occur. For example, using a data reference to pass buffer ownership can result in the buffer being lost, which is comparable to a memory leak and, in the worst case, can cause the system to run out of memory. Also, releasing a buffer while it is still in use by the receiver can, in the worst case, result in the sender writing to the buffer while it is still being read by the receiver. This can result in undefined behavior or a crash. Summary of the Invention

[0024]

[0040] Thus, a method, system, and non-transitory computer-readable medium for secure shared memory communication between processes is disclosed.

[0025]

[0041] In one embodiment, the method uses at least one hardware processor to: create and maintain a first data structure in a shared memory for communicating data references to data in the shared memory from a sender to a receiver, the first data structure including: a first queue of data references readable and writable by the sender and readable by the receiver, a first write index indicating a write location in the first queue, the first write index being readable and writable by the sender and readable by the receiver, and a first read index indicating a read location in the first queue, the first read index being readable by the sender and readable and writable by the receiver.

[0026]

[0042] The method may further include the steps of: determining, by the sender, to send data to the receiver; reading a first read index; determining whether the first read index is valid; switching to a safe state if it is determined that the first read index is invalid; and performing a write operation in the shared memory if it is determined that the first read index is valid. The write operation may include an enqueue operation, which may include adding a new data reference to a first queue at a write location indicated by the first write index and updating the first write index. Updating the first write index may include incrementing the first write index. The write operation may further include writing at least one data item to a data region of the shared memory before performing the enqueue operation; and obtaining a data reference to an address of the at least one data item in the data region of the shared memory as the new data reference to be added to the first queue in the enqueue operation. The method may further include repairing the first data structure in the safe state. The method may further include generating and maintaining, by the sender, a redundant copy of the first data structure in a local memory of the sender, and repairing the first data structure may include restoring, by the sender, the first data structure from the redundant copy of the first data structure in the local memory of the sender. Determining whether the first read index is valid may include reading the first write index, determining whether the first read index is greater than the first write index, determining that the first read index is valid if it is determined that the first read index is not greater than the first write index, and determining that the first read index is invalid if it is determined that the first read index is greater than the first write index.

[0027]

[0043] The method of claim 1 may further include, by the receiver, reading the first write index, determining whether the first write index is valid, switching to a safe state if it is determined that the first write index is invalid, and performing a read operation in the shared memory if it is determined that the first write index is valid. The read operation may include a dequeue operation, which may include reading at least one data reference from the first queue at a read location indicated by the first read index and updating the first read index. The updating of the first read index may include incrementing the first read index. The read operation may further include, after reading the at least one data reference from the first queue, determining whether the at least one data reference is valid, switching to a safe state if it is determined that the at least one data reference is invalid, and reading data at an address referenced by the at least one data reference from a data area of ​​the shared memory if it is determined that the at least one data reference is valid.

[0010] Determining whether the at least one data reference is valid may include determining whether an address referenced by the at least one data reference is within a data region of the shared memory, determining the at least one data reference is valid if the address is determined to be within the data region of the shared memory, and determining the at least one data reference is invalid if the address is determined to be not within the data region of the shared memory. The method may further include repairing the first data structure in the safe state. The method may further include generating and maintaining, by the receiver, a redundant copy of the first data structure in the receiver's local memory, and repairing the first data structure may include restoring, by the receiver, the first data structure from the redundant copy of the first data structure in the receiver's local memory.

[0028]

[0044] The method may further include, using at least one hardware processor, generating and maintaining a second data structure in the shared memory for communicating data references to data in the shared memory from the receiver to the sender, the second data structure including: a second queue of data references that is readable and writable by the receiver and readable by the sender; a second write index indicating a write location in the second queue, the second write index being readable and writable by the receiver and readable by the sender; and a second read index indicating a read location in the second queue, the second read index being readable by the receiver and readable and writable by the sender. The method may further include, using at least one hardware processor, transferring ownership of the data in the shared memory from the sender to the receiver by the sender enqueuing data references to the data in a first queue of the first data structure, and returning ownership of the data in the shared memory from the receiver to the sender by the receiver enqueuing those data references to the data in a second queue of the second data structure.

[0029]

[0045] In one embodiment, the first queue and the first write index are not writable by the receiver and the first read index is not writable by the sender. In an alternative embodiment, the first queue and the first write index are writable by the receiver and the first read index is writable by the sender.

[0030]

[0046] It should be understood that any of the features in the above-described methods may be implemented individually or in any combination with any subset of the other features. Thus, to the extent that the appended claims suggest particular dependencies between features, the disclosed embodiments are not limited to those particular dependencies. Rather, any of the features described herein may be combined with other features described herein, or may be implemented in any combination of features without one or more other features described herein. Additionally, any of the methods described above and elsewhere herein may be embodied, individually or in any combination, in executable software modules of a processor-based system, such as a server, and / or in executable instructions stored on a non-transitory computer-readable medium. [Brief explanation of the drawings]

[0031]

[0047] The details of the present invention, both as to its structure and operation, may be learned in part by study of the accompanying drawings. [Figure 1A]

[0048] FIG. 1A illustrates a shared memory for communication between a sender and a receiver, according to one embodiment. [Figure 1B] FIG. 1B illustrates a shared memory for communication between a sender and a receiver, according to one embodiment. [Figure 1C] FIG. 1C illustrates a shared memory for communication between a sender and a receiver, according to one embodiment. [Figure 2]

[0049] FIG. 2 is a diagram illustrating the process of writing to a lock-free data structure, according to one embodiment. [Figure 3]

[0050] FIG. 3 illustrates the process of reading from a lock-free data structure, according to one embodiment. [Figure 4]

[0051] FIG. 4 illustrates an exemplary processing system in which one or more of the processes described herein may be performed, according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0032]

[0052] After reading this specification, it will become apparent to those skilled in the art how to implement the invention in various alternative embodiments and alternative applications. However, while various embodiments of the present invention are described herein, it should be understood that these embodiments are offered by way of illustration and description only, and not by way of limitation. Therefore, this detailed description of various embodiments should not be construed as limiting the scope or breadth of the invention, which is defined in the appended claims.

[0033]

[0053] (1. Introduction)

[0054] The disclosed embodiments provide a secure mechanism for communicating data using one or more data structures in a shared memory. In embodiments, each data structure is a queue for transferring ownership of a memory region (e.g., a buffer) used for data communication between at least one sender and at least one receiver. The disclosed embodiments can provide interference-free communication as defined by the ISO 26262 standard.

[0034]

[0055] The disclosed embodiments may include one or more (including potentially all) of the following attributes.

[0056] (1) It does not use locks. Instead, lock-free data structures (e.g., queues with corresponding control data) are used to transfer ownership of memory regions in shared memory, thereby preventing blocking and potential deadlocks.

[0057] (2) Each lock-free data structure contains multiple components, each with defined read and write access rights. This prevents the sender and receiver from corrupting the memory of other communicating entities. The components of each lock-free data structure may be distributed across different areas of shared memory so that there is no duplication of information, or so that some of the information is stored in multiple memory areas in duplicate. The components of a lock-free data structure may have different access rights. Possible access rights include both communicating entities having read and write access to the component, one communicating entity having write access to the component and the other having only read access, or one communicating entity having read and write access to the component and the other having no access at all.

[0058] (3) At least one component of the lock-free data structure stored in an area of ​​the shared memory that can be read by one communicating entity and written to by another communicating entity is further protected by a validity check. The validity check can detect when a communicating entity with write access has corrupted the component. For example, the validity check may check the value of the component against an invariant (e.g., determine whether the value of the component is outside an allowed value or range of values), compare the value of the component to a redundant value of the component in another area of ​​the shared memory, and / or the like.

[0059] (4) By virtue of (1) and (2), ownership of memory regions in shared memory is transferred between sender and receiver using lock-free, memory-isolated data structures. This eliminates the need to use shared control data, such as reference counters, to manage ownership, which could result in the control data being corrupted by the communicating entities.

[0035]

[0060] (2. Data Structure)

[0061] In one embodiment, a lock-free data structure is used within a shared memory to transfer ownership of a memory region that stores data. The components of this lock-free data structure can be distributed across two or more memory regions within the shared memory. Distributing the components ensures that both the sender and receiver have the minimum access rights necessary for secure communication. To maintain the integrity of the lock-free data structure, the sender and / or receiver can perform validity checks on the components, which allows potential corruption to be detected and optionally repaired.

[0036]

[0062] 1A shows a shared memory 130 for communication between a first communication entity 110 and a second communication entity 120 according to a first embodiment. In this first embodiment, the first communication entity 110 is the sender and the second communication entity 120 is the receiver. In other words, the first communication entity 110 transmits data to the second communication entity 120 and the second communication entity 120 receives data from the first communication entity 110.

[0037]

[0063] The shared memory includes a data area 140. The data area 140 is protected by a set of access rights. In particular, the access rights to the data area 140 include the first communication entity 110 having both read and write access to the data area 140 and the second communication entity 120 having read access but not write access to the data area 140. In other words, the data area 140 is both readable and writable by the sender and only readable by the receiver. The data area 140 may be configured to store one or more data items representing a payload to be transmitted by the sender to the receiver. For example, the data area 140 may encompass an address range of the shared memory 130, and the first communication entity 110 may have write access to a memory block at each memory address within the address range. As used herein, it should be understood that the term “data reference” refers to a pointer or other reference to a memory address within the data area 140 of the shared memory 130.

[0038]

[0064] Shared memory 130 also includes data structure 150, which illustrates one embodiment of a lock-free data structure. Data structure 150 may be composed of multiple components. In particular, data structure 150 may be composed of queue 152, write index 154, and read index 156. In one embodiment, queue 152 stores a data reference to data region 140, as opposed to storing the actual data to be transmitted. However, in an alternative embodiment, queue 152 may directly store the data to be transmitted. Write index 154 indicates a write position within queue 152, and read index 156 indicates a read position within queue 152. In particular, the value of write index 154 represents the current write position within queue 152, and the value of read index 156 represents the current read position within queue 152. Collectively, the values ​​of write index 154 and read index 156 represent the state of queue 152.

[0039]

[0065] Each component of data structure 150 is protected by a set of access rights. In particular, the access rights to queue 152 include the first communication entity 110 having both read and write access to queue 152 and the second communication entity 120 having read access but not write access to queue 152. The access rights to write index 154 include the first communication entity 110 having both read and write access to write index 154 and the second communication entity 120 having read access but not write access to write index 154. The access rights to read index 156 include the first communication entity 110 having read access but not write access to read index 156 and the second communication entity 120 having both read and write access to read index 156. In other words, queue 152 is readable and writable by the sender and readable only by the receiver, write index 154 is readable and writable by the sender and readable only by the receiver, and read index 156 is readable only by the sender and readable and writable by the receiver.

[0040]

[0066] The first communication entity 110 may utilize the queue 152 of the data structure 150 to transmit a data reference to the data region 140 to the second communication entity 120. In particular, the first communication entity 110 may write a data item to the data region 140 and enqueue the data reference to the data item in the data region 140 into the queue 152. This enqueueing operation may consist of adding the data reference onto the queue 152 at a write location identified by the current value of the write index 154 (e.g., representing the rear of the queue 152) and then updating (e.g., incrementing by one) the value of the write index 154. Alternatively, this enqueueing operation may consist of updating (e.g., incrementing by one) the value of the write index 154 and then adding the data reference onto the queue 152 at a write location identified by the updated value of the write index 154. In either case, for each data item written to data area 140, first communication entity 110 performs an enqueue operation that adds a data reference to that data item in data area 140 to queue 152 and updates write index 154 accordingly.

[0041]

[0067] At the other end of the communication path, the second communication entity 120 may receive a data reference to data area 140 from the first communication entity 110 using queue 152 of data structure 150. In particular, the second communication entity 120 may dequeue the data reference to a data item in data area 140 and read the data item to which the data reference refers from data area 140. This dequeue operation may include reading the data reference from queue 152 at a read position identified by the current value of read index 156 (e.g., representing the head of queue 152) and then updating (e.g., incrementing by one) the value of read index 156. Alternatively, this dequeue operation may include updating (e.g., incrementing by one) the value of read index 156 and then reading the data reference from queue 152 at the read position identified by the updated value of read index 156. In either case, the second communication entity 120 performs a dequeue operation that reads the data reference to the data item in the data region 140 from the queue 152 and updates the read index 154 accordingly, thereby effectively removing the data reference from the queue 152.

[0042]

[0068] Notably, the number of unread data references in queue 152 can be determined as the difference between write index 154 and read index 156, which are components to which both first communicating entity 110 and second communicating entity 120 have read access. Thus, either communicating entity can read write index 154 and read index 156 and subtract read index 156 from write index 154 to determine the number of data references to data region 140 in queue 152 that have been queued by first communicating entity 110 and have not yet been dequeued by second communicating entity 120. This is particularly useful from the perspective of second communicating entity 120, which can dequeue all unread data references at once based on the difference between write index 154 and read index 156.

[0043]

[0069] 1B shows a diagram of a shared memory 130 for communication between a first communicating entity 110 and a second communicating entity 120 according to a second embodiment. As in the first embodiment, the first communicating entity 110 is the sender and the second communicating entity 120 is the receiver.

[0044]

[0070] In this second embodiment, data area 140 is protected by the same set of access rights as in the first embodiment. However, the components of shared data structure 150A in shared memory 130 are protected by a different set of access rights. In particular, the access rights are such that first communicating entity 110 has both read and write access to each of queue 152, write index 154, and read index 156, and second communicating entity 120 also has both read and write access to each of queue 152, write index 154, and read index 156. In other words, queue 152 is readable and writable by the sender and readable and writable by the receiver, write index 154 is readable and writable by the sender and readable and writable by the receiver, and read index 156 is readable and writable by the sender and readable and writable by the receiver.

[0045]

[0071] Furthermore, in this second embodiment, the first communication entity 110 and the second communication entity 120 each maintain redundant local copies of the shared data structure 150A in the shared memory 130. In particular, the first communication entity 110 maintains a redundant first local data structure 150B, and the second communication entity 120 maintains a redundant second local data structure 150C. Each of the local data structures 150B and 150C are synchronized with the shared data structure 150A so that they are identical to the shared data structure 150A. However, the first local data structure 150B is stored in the local memory of the first communication entity 110 such that the first communication entity 110 has both read and write access to each component of the first local data structure 150B (i.e., the queue 152, the write index 154, and the read index 156), while the second communication entity 120 has neither read nor write access to any component of the first local data structure 150B. Similarly, the second local data structure 150C is stored in the local memory of the second communication entity 120 such that the second communication entity 120 has both read and write access to each component of the second local data structure 150C (i.e., the queue 152, the write index 154, and the read index 156), and the first communication entity 110 has neither read nor write access to any component of the second local data structure 150C.

[0046]

[0072] In this second embodiment, the enqueue and dequeue operations may be identical to those in the first embodiment. However, after each enqueue and dequeue operation, the first and second communication entities 110 and 120 may each update their respective local data structures 150B and 150C in their respective local memories to match the shared data structure 150A in the shared memory 130. For example, the first communication entity 110 may read each element of the shared data structure 150A and synchronize the corresponding elements of the first local data structure 150B with the shared data structure 150A. Similarly, the second communication entity 120 may read each element of the shared data structure 150A and synchronize the corresponding elements of the second local data structure 150C with the shared data structure 150A.

[0047]

[0073] The first communicating entity 110 and / or the second communicating entity 120 may utilize their respective local data structures 150B and 150C to perform validity checks as described elsewhere herein. For example, the first communicating entity 110 may compare the data reference in queue 152 in shared data structure 150 with the data reference in queue 152 in first local data structure 150B, compare the write index 154 in shared data structure 150 with the write index 154 in first local data structure 150B, compare the read index 156 in shared data structure 150 with the read index 156 in first local data structure 150B, and / or the like to detect possible corruption in shared data structure 150A. Similarly, the second communicating entity 120 may compare the data reference in queue 152 in shared data structure 150A with the data reference in queue 152 in second local data structure 150C, compare the write index 154 in shared data structure 150 with the write index 154 in second local data structure 150C, compare the read index 156 in shared data structure 150 with the read index 156 in second local data structure 150C, and / or the like, to detect possible corruption in shared data structure 150A. Upon detecting possible corruption, the first communicating entity 110 and / or the second communicating entity 120 may proceed to a safe state, in which each communicating entity may attempt to restore or otherwise repair shared data structure 150A from its respective local data structure (e.g., 150B or 150C) using its respective write access to shared data structure 150A.

[0048]

[0074] Although local data structures 150B and 150C are illustrated as consisting of complete copies of shared data structure 150A, in alternative embodiments, local data structures 150B and 150C consist of only the components of shared data structure 150A necessary for the validity checks performed by first and second communication entities 110 and 120. For example, each of local data structures 150B and 150C may include only copies of write index 154 and read index 156, and not a copy of queue 152, if validity checks are performed on write index 154 and / or read index 156, but not on the data references themselves. Advantageously, this may reduce the memory footprint required by local data structures 150B and 150C.

[0049]

[0075] Although not required, it is generally assumed that validity checks are performed before processing any information in shared data structure 150A. For example, information may be read from shared data structure 150A, and then one or more validity checks may be performed on the information read from shared data structure 150A (e.g., comparing the information with corresponding information in local data structures 150B or 150C, determining whether the information makes sense, etc.), and if the information passes the validity checks, the information is processed and shared data structure 150A and local data structures 150B and 150C are updated accordingly. If the information does not pass the validity checks, the system may enter a safe state, as described elsewhere herein.

[0050]

[0076] 1C shows a shared memory 130 for communication between a first communicating entity 110 and a second communicating entity 120 according to a third embodiment. As in the first and second embodiments, the first communicating entity 110 is the sender and the second communicating entity 120 is the receiver.

[0051]

[0077] In untrusted environments, conventional techniques that utilize control data (e.g., reference counters) are impractical due to the risk that a process could corrupt the control data and cause a resource leak. A third embodiment overcomes this problem by using two data structures 150A and 150B in shared memory 130. Each data structure 150A and 150B contains a set of components, each protected by a set of access rights, where the set of access rights for the components of the second data structure 150B is the opposite of the set of access rights for the components of the first data structure 150A. In other respects, data structures 150A and 150B may be similar or identical.

[0052]

[0078] In one embodiment, the access rights to queue 152A of first data structure 150A include the first communication entity 110 having both read and write access to queue 152A and the second communication entity 120 having read access but not write access to queue 152A. The access rights to write index 154A of first data structure 150A include the first communication entity 110 having both read and write access to write index 154A and the second communication entity 120 having read access but not write access to write index 154A. The access rights to read index 156A of first data structure 150A include the first communication entity 110 having read access but not write access to read index 156A and the second communication entity 120 having both read and write access to read index 156A. In other words, queue 152A is readable and writable by the sender and readable only by the receiver, write index 154 is readable and writable by the sender and readable only by the receiver, and read index 156 is readable only by the sender and readable and writable by the receiver.

[0053]

[0079] Conversely, the access rights to queue 152B in second data structure 150B include the second communication entity 120 having both read and write access to queue 152B and the first communication entity 110 having read access but not write access to queue 152B. The access rights to write index 154B in second data structure 150B include the second communication entity 120 having both read and write access to write index 154B and the first communication entity 110 having read access but not write access to write index 154B. The access rights to read index 156B in second data structure 150B include the second communication entity 120 having read access but not write access to read index 156B and the first communication entity 110 having both read and write access to read index 156B. In other words, queue 152B is readable and writable by the receiver and readable only by the sender, write index 154 is readable and writable by the receiver and readable only by the sender, and read index 156 is readable only by the receiver and readable and writable by the sender.

[0054]

[0080] During the data transfer, the first communication entity 110 utilizes the first data structure 150A to transfer ownership of the data in the data area 140 to the second communication entity 120 by queuing a data reference to the data in queue 152A of the first data structure 150A. The second communication entity 120 dequeues the data reference from queue 152A of the first data structure 150A and reads the data referenced by the dequeued data reference from the data area 140. When the second communication entity 120 no longer needs the referenced data in the data area 140, the second communication entity 120 returns ownership of the data to the first communication entity 110 by queuing a data reference to the data in queue 152B of the second data structure 150B. The first communication entity 110 dequeues the data reference from queue 152B of the second data structure 150B, freeing the data in the data area 140 referenced by the dequeued data reference for subsequent writing. In summary, ownership of data in shared memory 130 (e.g., data in data area 140) is transferred from a sender to a receiver by the sender enqueuing a data reference to the data into queue 152A of first data structure 150A, and ownership of the data in shared memory 130 is transferred back from the receiver to the sender by the receiver enqueuing those data references to the data into queue 152B of second data structure 150B. This two-structure approach enhances security and reliability in untrusted environments and mitigates the risks associated with conventional techniques for transferring data ownership.

[0055]

[0081] It should be understood that the three embodiments described above are merely three example embodiments and, as such, do not represent all possible embodiments. These embodiments may be combined with each other, may form additional data structures, may form different data structures (e.g., having fewer, additional, and / or different components), and / or may be similar. This disclosure is not directed to any particular implementation of data structure 150.

[0056]

[0082] Rather, this disclosure is directed to an approach that separates the data structures in shared memory 130 into separate components, each with a set of access rights for the first communicating entity 110 and the second communicating entity 120, and allows validity checks to be performed when one communicating entity is reading from a data structure to which the other communicating entity has write access. In certain embodiments (e.g., the first and third embodiments described above), each data structure 150 is divided into at least two segments with different access rights. To the first segment (e.g., including or consisting of queue 152 and write index 154), the first communicating entity 110 (e.g., sender) has write access, and the second communicating entity 120 (e.g., receiver) has read-only access. To the second segment (e.g., including or consisting of read index 156), the second communicating entity 120 (e.g., receiver) has write access, and the first communicating entity 110 (e.g., sender) has read-only access. Alternative embodiments may utilize a data structure having more than two segments, provide both the first communication entity 110 and the second communication entity 120 with write access to at least one segment of the data structure (e.g., as in the second embodiment described above), and / or the like.

[0057]

[0083] A data structure 150 or a set of data structures 150 (e.g., 150A-150C in the second embodiment, 150A and 150B in the third embodiment, etc.) may be generated and maintained in the shared memory 130 for each communication path between a pair of communicating entities. For example, a first communicating entity 110 may transmit data to multiple second communicating entities 120 via respective sets of one or more data structures 150 in the same shared memory 130 or in respective shared memories 130. Furthermore, a second communicating entity 120 may transmit data to the first communicating entity 110 via one or more sets of data structures 150 in the same shared memory 130 or in different shared memories 130, such that bidirectional communication (i.e., a bidirectional communication path) exists between the first communicating entity 110 and the second communicating entity 120. In general, for each communication path requiring interference-free secure communication and utilizing shared memory 130, a data structure 150 may be generated and maintained in shared memory 130 for communicating a data reference to data in shared memory 130 (e.g., in data area 140) from a sender to a receiver in the system. In embodiments in which ownership of data is transferred from the receiver back to the sender (e.g., the third embodiment described above), a second data structure 150B may also be generated and maintained in shared memory 130 for communicating a data reference from the receiver to the sender, thereby transferring ownership of the referenced data in data area 140 back to the sender. Shared memory 130 and / or data structure 150 may be generated by the first communicating entity 110 as sender, by the second communicating entity 120 as receiver, and / or by, e.g., a generic process that manages shared memory 130 for multiple communicating entities.

[0058]

[0084] (3. Burning process)

[0085] 2 illustrates a process 200 for writing to a data structure 150, according to an embodiment. The process 200 may be performed by the first communicating entity 110 as the sender of data. Although the process 200 is illustrated with a particular arrangement and order of sub-processes, the process 200 may be implemented with fewer, more, or different sub-processes, as well as with a different arrangement and / or order of the sub-processes. Additionally, it should be understood that any sub-process that is not dependent on the completion of other sub-processes may be performed before, after, or in parallel with other independent sub-processes, even if the sub-processes are described or illustrated in a particular order.

[0059]

[0086] In sub-process 205, process 200 may determine whether to terminate. Process 200 may execute as long as the first communication entity 110 is performing or carrying out communication with the second communication entity 120. In this case, process 200 may determine to terminate when the first communication entity 110 shuts down or terminates communication with the second communication entity 120. If the determination is to terminate (i.e., "Yes" in sub-process 205), process 200 may terminate. Otherwise, if the determination is not to terminate or if the determination is to continue (i.e., "No" in sub-process 205), process 200 may proceed to sub-process 210.

[0060]

[0087] In sub-process 210, process 200 may determine whether to send data to a recipient. In particular, first communication entity 110 may decide to write one or more data items to data area 140 of shared memory 130. Process 200 may decide to write a data item whenever first communication entity 110 needs to communicate a data item to second communication entity 120. If it decides to write at least one data item to data area 140 (i.e., "Yes" in sub-process 210), process 200 may proceed to sub-process 215. Otherwise, if it does not decide to write a data item to data area 140 (i.e., "No" in sub-process 210), process 200 may return to sub-process 205 and continue waiting for a request to communicate a data item to second communication entity 120.

[0061]

[0088] In sub-process 215, process 200 may read read index 156. In particular, first communication entity 110 may read the value of read index 156 of data structure 150 in shared memory 130 between first communication entity 110 and second communication entity 120. As discussed elsewhere herein, first communication entity 110 may have read access to read index 156. Read index 156 identifies the current read position within queue 152 of data structure 150.

[0062]

[0089] In sub-process 220, process 200 may perform a validity check on the current value of read index 156. At a high level, the validity check may determine whether the current value of read index 156 is valid relative to, for example, the current value of write index 154. For example, sub-process 220 may read both write index 154 and read index 156 and determine whether the current value of read index 156 is greater than the current value of write index 154. If the current value of read index 156 is greater than the current value of write index 154, sub-process 220 may output a determination that the current value of read index 156 is not valid. Conversely, if the current value of read index 156 is not greater than the current value of write index 154, sub-process 220 may output a determination that the current value of read index 156 is valid. It should be understood that this is merely one example of a validity test, and that the validity check may include additional or alternative validity tests to detect whether read index 156 is valid. Validity checks may ensure that reads and writes are not performed to memory regions outside the bounds of queue 152 and / or shared memory 130.

[0063]

[0090] In sub-process 225, the output of the validity check in sub-process 220 may be evaluated to determine whether read index 156 is determined to be valid. If read index 156 is determined to be valid (i.e., "Yes" in sub-process 225), process 200 may proceed to sub-process 230. Otherwise, when read index 156 is determined to be invalid (i.e., "No" in sub-process 225), process 200 may proceed to sub-process 260.

[0064]

[0091] After determining in sub-process 230 that the current value of read index 156 is valid, process 200 may write the data item to data area 140 in shared memory 130. As discussed elsewhere herein, first communication entity 110 may have write access to data area 140.

[0065]

[0092] In sub-process 235, process 200 may obtain a data reference to the data item(s) written to data area 140. It should be understood that the data reference is to the address of the data item within data area 140 of shared memory 130.

[0066]

[0093] In sub-process 240, process 200 may read write index 154. In particular, first communication entity 110 may read the value of write index 154 of data structure 150 in shared memory 130 between first communication entity 110 and second communication entity 120. As described elsewhere herein, first communication entity 110 has read access to write index 154. Write index 154 identifies the current write position within queue 152 of data structure 150.

[0067]

[0094] In sub-process 245, process 200 may add the data reference obtained in sub-process 235 as a new data reference to queue 152 at the write location indicated by the value of write index 154 read in sub-process 240. As discussed elsewhere herein, first communication entity 110 has write access to queue 152.

[0068]

[0095] In sub-process 250, process 200 may update write index 154. As discussed elsewhere herein, first communicating entity 110 has write access to write index 154. In contemplated embodiments, updating write index 154 in sub-process 250 involves incrementing write index 154 by a value of 1 (or an alternative step value). However, the particular implementation of sub-process 250 depends on the particular implementation of write index 154 and read index 156.

[0069]

[0096] Sub-processes 230-250 represent an enqueue operation in which first communicating entity 110 adds a data reference to a data item in data region 140 to queue 152 at a position indicated by the value of write index 154 and updates write index 154 accordingly. Alternatively, sub-processes 230-250 may be replaced by another type of write operation, such as a dequeue operation in which first communicating entity 110 removes the data reference from queue 152, or a modify operation in which first communicating entity 110 modifies an existing data reference in queue 152. Although not specifically shown, the write operation may include a validity check on write index 154 (e.g., between sub-processes 240 and 245), which may be similar to the validity check on read index 156 in sub-process 220. In any case, after the write operation is completed, process 200 may return to sub-process 205.

[0070]

[0097] In sub-process 260, process 200 may switch to a safe state to prevent, mitigate, repair, and / or otherwise address potential corruption of data structure 150. For example, the safe state may configure or initiate a process that attempts to repair data structure 150 by attempting to determine the correct value of read index 156 (e.g., from local data structure 150B), restore data structure 150 from a redundant copy of data structure 150 (e.g., restore shared data structure 150A from local data structure 150B), reinitialize data structure 150, reset communications between first communication entity 110 and second communication entity 120, and / or the like. As discussed elsewhere in this specification, the first communication entity 110 may generate and maintain a redundant copy of the data structure 150 in its local memory, in which case the first communication entity 110 may attempt to repair the data structure 150 by restoring the data structure 150 from the redundant copy of the data structure 150 in the first communication entity 110's local memory.

[0071]

[0098] In sub-process 265, process 200 may determine whether potential corruption in data structure 150 has been resolved by sub-process 260. If process 200 determines that potential corruption in data structure 150 has been resolved (i.e., "Yes" in sub-process 265), process 200 may return to sub-process 205. Otherwise, when process 200 determines that potential corruption in data structure 150 has not been resolved (i.e., "No" in sub-process 265), process 200 may remain in sub-process 260 to continue attempting to resolve the potential corruption in data structure 150. In one embodiment, each subsequent iteration of sub-process 260 may escalate the manner in which repair of data structure 150 is attempted, for example, by taking more aggressive repair actions than previous iterations of sub-process 260.

[0072]

[0099] (4. Reading process)

[0100] 3 illustrates a process 300 for reading from data structure 150, according to an embodiment. Process 300 may be performed by second communicating entity 120 as a recipient of data. Although process 300 is illustrated with a particular arrangement and order of subprocesses, process 300 may be implemented with fewer, more, or different subprocesses, as well as a different arrangement and / or order of the subprocesses. Additionally, it should be understood that any subprocess that is not dependent on the completion of other subprocesses may be performed before, after, or in parallel with other independent subprocesses, even if the subprocesses are described or illustrated in a particular order.

[0073]

[0101] In sub-process 305, process 300 may determine whether to terminate. Process 300 may execute as long as the second communication entity 120 is performing or carrying out communication with the first communication entity 110. In this case, process 300 may determine to terminate when the second communication entity 120 shuts down or terminates communication with the first communication entity 110. If the determination is to terminate (i.e., "Yes" in sub-process 305), process 300 may terminate. Otherwise, if the determination is not to terminate or if the determination is to continue (i.e., "No" in sub-process 305), process 300 may proceed to sub-process 310.

[0074]

[0102] In sub-process 310, process 300 may determine whether to read data from the sender. Process 300 may decide to read data whenever the value of write index 154 changes, periodically (e.g., at regular time intervals, after completely processing previously received data, etc.), whenever second communication entity 120 expects a communication from first communication entity 110, and / or similar occasions. If it decides to read data (i.e., "Yes" in sub-process 310), process 300 may proceed to sub-process 315. Otherwise, process 300 may return to sub-process 305 and wait until it decides to read data (i.e., "No" in sub-process 310).

[0075]

[0103] In sub-process 315, process 300 may read write index 154. In particular, second communication entity 120 may read the value of write index 154 of data structure 150 in shared memory 130 between first communication entity 110 and second communication entity 120. As discussed elsewhere herein, second communication entity 120 may have read access to write index 154. Write index 154 identifies the current write position within queue 152 of data structure 150.

[0076]

[0104] In sub-process 320, process 300 may perform a validity check on the current value of write index 154. At a high level, the validity check may determine whether the current value of write index 154 is valid relative to, for example, the current value of read index 156. For example, sub-process 320 may read both write index 154 and read index 156 and determine whether the current value of write index 154 is less than the current value of read index 156. If the current value of write index 154 is less than the current value of read index 156, sub-process 320 may output a determination that the current value of write index 154 is not valid. Conversely, if the current value of write index 154 is not less than the current value of read index 156, sub-process 320 may output a determination that the current value of write index 154 is valid. It should be understood that this is merely one example of a validity test, and that the validity check may include additional or alternative validity tests to determine whether write index 154 is valid. Validity checks may ensure that writes and reads are not performed to memory regions outside the bounds of queue 152 and / or shared memory 130.

[0077]

[0105] In sub-process 325, the output of the validity check in sub-process 320 may be evaluated to determine whether the writing index 154 is determined to be valid. If the writing index 154 is determined to be valid (i.e., "Yes" in sub-process 325), process 300 may proceed to sub-process 330. Otherwise, when the writing index 154 is determined to be invalid (i.e., "No" in sub-process 325), process 300 may proceed to sub-process 360.

[0078]

[0106] In sub-process 330, process 300 may read read index 156. In particular, second communication entity 120 may read the value of read index 156 of data structure 150 in shared memory 130 between first communication entity 110 and second communication entity 120. As described elsewhere herein, second communication entity 120 has read access to read index 156. Read index 156 identifies the current read position within queue 152 of data structure 150.

[0079]

[0107] In sub-process 335, process 300 may read one or more data references from queue 152, starting from the read position indicated by the value of read index 156 read in sub-process 330. As discussed elsewhere herein, second communication entity 120 has read access to queue 152. In embodiments of sub-process 335, process 300 may read all unread data references from queue 152 at once. In particular, second communication entity 120 may read all data references starting from the value of read index 156 read in sub-process 330 and ending at or just before the value of write index 154 read in sub-process 315. In such embodiments, the number of data references read may be equal to the difference between the value of write index 154 and the value of read index 156. In alternative embodiments, process 300 may read only a single data reference from queue 152 at a time.

[0080]

[0108] In sub-process 340, process 300 may perform a validity check on the data reference(s) read in sub-process 335. At a high level, the validity check may determine whether the data reference(s) are valid. For example, second communication entity 120 may store in shared memory 130 an address range encompassed by data area 140. In this case, sub-process 340 may determine whether each of the data references is to an address within this address range. If the data reference is to an address outside the address range of data area 140, sub-process 340 may output a determination that the data reference(s) is invalid. Conversely, if each data reference points to an address within the address range of data area 140, sub-process 340 may output a determination that the data reference(s) is valid. More generally, process 300 determines whether the address referenced by each data reference is within data area 140 of shared memory 130. It should be understood that this is merely one example of a validity test, and that the validity check may include additional or alternative validity tests to detect whether the data reference(s) are valid. The validity check may ensure that reads are not performed on memory regions that are outside the bounds of data region 140 and / or shared memory 130.

[0081]

[0109] In sub-process 345, the output of the validity check in sub-process 340 may be evaluated to determine whether the data reference is determined to be valid. If the data reference is determined to be valid (i.e., "Yes" in sub-process 345), process 300 may proceed to sub-process 350. Otherwise, when the data reference is determined to be invalid (i.e., "No" in sub-process 345), process 300 may proceed to sub-process 360.

[0082]

[0110] In sub-process 350, process 300 may update read index 156. As discussed elsewhere herein, second communication entity 120 has write access to read index 156. In contemplated embodiments, updating read index 156 in sub-process 350 involves incrementing read index 156 by a value of 1 (or an alternative step value). However, the particular implementation of sub-process 350 depends on the particular implementation of write index 154 and read index 156.

[0083]

[0111] In sub-process 355, for each data reference read in sub-process 335, process 300 reads the data (e.g., one or more data items) at the address referenced by that data reference from data area 140 of shared memory 130. It should be understood that second communication entity 120 may process the data read in sub-process 355 according to the particular functionality of second communication entity 120. The particular way the data is used is not relevant to the operation of process 300, which is concerned only with reading data transmitted by first communication entity 110.

[0084]

[0112] Sub-processes 330-350 represent dequeue operations in which second communicating entity 120 removes a data reference to a data item in data region 140 from queue 152 at a position indicated by the value of read index 156 and updates read index 156 accordingly. Alternatively, sub-processes 330-350 may be replaced by another type of read operation, such as reading the modified data reference from queue 152. In any case, after sub-process 355, process 300 may return to sub-process 305.

[0085]

[0113] In sub-process 360, process 300 may switch to a safe state to prevent, mitigate, repair, and / or otherwise address potential corruption of data structure 150. Sub-process 360 may be similar to or identical to sub-process 260 of process 200. For example, the safe state may constitute or initiate a process that attempts to repair data structure 150 by attempting to determine the correct value of write index 154 (e.g., from local data structure 150C) or data reference (e.g., read in sub-process 335), restore data structure 150 from a redundant copy of data structure 150 (e.g., restore shared data structure 150A from local data structure 150C), reinitialize data structure 150, reset communication between first communication entity 110 and second communication entity 120, and / or the like. As discussed elsewhere in this specification, the second communication entity 120 may generate and maintain a redundant copy of the data structure 150 in its local memory, in which case the second communication entity 120 may attempt to repair the data structure 150 by restoring the data structure 150 from the redundant copy of the data structure 150 in the local memory of the second communication entity 120.

[0086]

[0114] In sub-process 365, process 300 may determine whether potential corruption in data structure 150 has been resolved by sub-process 360. Sub-process 365 may be similar or identical to sub-process 265 of process 200. If process 300 determines that potential corruption in data structure 150 has been resolved (i.e., "Yes" in sub-process 365), it may return to sub-process 305. Otherwise, when process 300 determines that potential corruption in data structure 150 has not been resolved (i.e., "No" in sub-process 365), it may remain in sub-process 360 to continue attempting to resolve the potential corruption in data structure 150. In one embodiment, each subsequent iteration of sub-process 360 may escalate the manner in which repair of data structure 150 is attempted, for example, by taking more aggressive repair actions than previous iterations of sub-process 360.

[0087]

[0115] (5. Application Examples)

[0116] The disclosed embodiments of shared memory 130 (e.g., including data structure 150), process 300, and / or process 400 may be used for any communication between a pair of entities, such as inter-process communication between two processes. The disclosed embodiments are particularly beneficial for high-performance communications that require interference-free communication between a sender (e.g., first communicating entity 110) and a receiver (e.g., second communicating entity 120). For example, the disclosed embodiments may be used in frameworks and / or middleware solutions for sensor-intensive systems. Examples of sensor-intensive systems include, but are not limited to, robotic control systems, autonomous vehicle or drone systems, etc.

[0088]

[0117] As an example, the first communicating entity 110 may be a sensing process that measures one or more parameters, and the second communicating entity 120 may be a control process that makes decisions and / or performs actions based on the measured parameter(s). In this case, the sensing process may utilize a data structure 150 in the shared memory 130 to transfer ownership of the measured parameter values ​​in the data area 140 to the control process. It should be understood that this is just one example, and that there are a virtually infinite number of other contexts and scenarios in which the disclosed embodiments may be used.

[0089]

[0118] The disclosed embodiments are described with respect to a first communicating entity 110 as a sender and a second communicating entity 120 as a receiver. However, the disclosed embodiments are not limited to one-way communication. Rather, the first communicating entity 110 may also be a receiver and / or the second communicating entity 120 may also be a sender. In this case, there may be a separate shared memory 130 with a separate data structure 150 for each communication path (i.e., a particular direction of communication between the first communicating entity 110 and the second communicating entity 120). Alternatively, there may be a single shared memory 130 with separate data structures 150 and potentially separate data areas 140 for each communication path.

[0090]

[0119] It should further be understood that the first communicating entity 110 and / or the second communicating entity 120 may communicate with other entities in addition to each other. In this case, there may be a separate shared memory 130 for each pair of communicating entities or for each communication path between the communicating entities. Alternatively, three or more communicating entities may utilize the same shared memory 130, with a separate data structure 150 and potentially a separate data area 140 for each communication path between the communicating entities. In general, on each communication path, there may be a data structure 150 or a set of data structures 150 (e.g., in the case of the third embodiment described above) for each communication direction between a pair of communicating entities. These data structures 150 may be stored in a single shared memory 130 or in separate shared memories 130. It should therefore be understood that a communicating entity may implement both the process 200 for sending data to another communicating entity and the process 300 for receiving data from another communicating entity.

[0091]

[0120] (6. Processing system example)

[0121] 4 illustrates an exemplary processing system 400 on which one or more of the processes described herein may be executed, according to an embodiment. For example, the system 400 may execute both the first communication entity 110 (e.g., executing process 200) and the second communication entity 120 (e.g., executing process 300), or the first communication entity 110 and the second communication entity 120 may execute on separate systems 400. Furthermore, the system 400 (e.g., executing the first communication entity 110 and / or the second communication entity 120) may host the shared memory 130. The system 400 may be any processor-enabled device (e.g., a server, a personal computer, etc.) and may be capable of wired or wireless data communication. As will be apparent to one skilled in the art, other processing systems and / or architectures may also be used.

[0092]

[0122] The system 400 may include one or more processors 410. The processor(s) 410 may include a central processing unit (CPU). Additional processors may be provided, such as graphics processing units (GPUs), auxiliary processors for managing input / output, auxiliary processors for performing floating-point mathematical operations, special-purpose microprocessors (e.g., digital signal processors) with architectures suitable for fast execution of signal processing algorithms, lower-level processors (e.g., back-end processors), additional microprocessors or controllers for dual or multiprocessor systems, and / or coprocessors. Such auxiliary processors may be separate processors or may be integrated with the main processor 410. Examples of processor 410 that may be used with system 400 include, but are not limited to, any of the processors available from Intel Corporation of Santa Clara, California (e.g., Pentium®, Core i7®, Xeon®, etc.), any of the processors available from Advanced Micro Devices (AMD) of Santa Clara, California, any of the processors available from Apple Inc. of Cupertino (A-series, M-series, etc.), any of the processors available from Samsung Electronics Co., Ltd. of Seoul, South Korea (e.g., Exynos®), any of the processors available from NXP Semiconductors of Eindhoven, The Netherlands, etc.

[0093]

[0123] The processor 410 may be connected to a communication bus 405. The communication bus 405 may include a data channel for facilitating information transfer between storage and other peripheral components of the system 400. Additionally, the communication bus 405 may provide a set of signals used for communication with the processor 410, including a data bus, an address bus, and / or a control bus (not shown). The communication bus 405 may include any standard or non-standard bus architecture, such as, for example, a bus architecture conforming to standards promulgated by the Institute of Electrical and Electronics Engineers (IEEE), including Industry Standard Architecture (ISA), Extended Industry Standard Architecture (EISA), MicroChannel Architecture (MCA), Peripheral Component Interconnect (PCI) local bus, IEEE 488 General Purpose Interface Bus (GPIB), IEEE 696 / S-100, and / or the like.

[0094]

[0124] System 400 may include main memory 415. Main memory 415 provides storage for programs (e.g., computer-executable instructions implementing processes 200 and / or 300) and data (e.g., shared memory 130) for programs executed on processor 410. It should be understood that the programs stored in memory and executed by processor 410 may be written and / or compiled according to any suitable language, including, but not limited to, C / C++, Java, JavaScript, Perl, Python, Visual Basic, .NET, etc. Main memory 415 is typically semiconductor-based memory, such as dynamic random access memory (DRAM) and / or static random access memory (SRAM). Other semiconductor-based memory types include, for example, synchronous dynamic random access memory (SDRAM), Rambus dynamic random access memory (RDRAM), ferroelectric random access memory (FRAM), etc., including read-only memory (ROM).

[0095]

[0125] System 400 may include secondary memory 420. Secondary memory 420 is a non-transitory computer-readable medium that may provide persistent, non-volatile storage of programs (e.g., computer-executable instructions implementing processes 200 and / or 300) and data for the programs (e.g., shared memory 130). As used herein, the term "computer-readable medium" refers to any non-transitory computer-readable storage medium used to provide computer-executable code and / or other data to or within system 400. Programs stored in secondary memory 420 may be loaded into main memory 415 for execution by processor 410. Secondary memory 420 may include, for example, semiconductor-based memory such as programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), flash memory (a block-oriented memory similar to EEPROM), etc.

[0096]

[0126] Secondary memory 420 may include internal media 425 and / or removable media 430. Internal media 425 and removable media 430 may be read from and / or written to in any known manner. Internal media 425 may include one or more hard disk drives, solid state drives, and / or the like. Removable storage media 430 may be, for example, a magnetic tape drive, a compact disc (CD) drive, a digital versatile disc (DVD) drive, other optical drive, a flash memory drive, and / or the like.

[0097]

[0127] System 400 may include an input / output (I / O) interface 435. I / O interface 435 provides an interface between one or more components of system 400 and one or more input and / or output devices. Examples of input devices include, but are not limited to, sensors, keyboards, touchscreens or other touch-sensitive devices, cameras, biometric sensing devices, computer mice, trackballs, pen-based pointing devices, and / or the like. Examples of output devices include, but are not limited to, other processing systems, cathode ray tubes (CRTs), plasma displays, light-emitting diode (LED) displays, liquid crystal displays (LCDs), printers, vacuum fluorescent displays (VFDs), surface-conduction electron emission displays (SEDs), field-emission displays (FEDs), and / or the like. In some cases, input and output devices may be combined, such as touch-sensitive displays (e.g., in smartphones, tablet computers, and other mobile devices).

[0098]

[0128] System 400 may include a communications interface 440. Communications interface 440 allows information to be transferred between system 400 and external devices (e.g., printers), networks, or other information sources. For example, programs and / or data may be transferred from a network server to system 400 over one or more networks (e.g., including the Internet) via communications interface 440, and / or vice versa. Examples of communications interface 440 include a built-in network adapter, a network interface card (NIC), a Personal Computer Memory Card International Association (PCMCIA) network card, a card bus network adapter, a wireless network adapter, a Universal Serial Bus (USB) network adapter, a modem, a wireless data card, a communications port, an infrared interface, an IEEE 1394 Firewire, and any other device that enables system 400 to interface with a network or another computing device. Communications interface 440 preferably implements industry-promulgated protocol standards such as the Ethernet IEEE 802 standard, Fibre Channel, Digital Subscriber Line (DSL), Asynchronous Digital Subscriber Line (ADSL), Frame Relay, Asynchronous Transfer Mode (ATM), Integrated Services Digital Network (ISDN), Personal Communications Services (PCS), Transmission Control Protocol / Internet Protocol (TCP / IP), Serial Line Internet Protocol / Point-to-Point Protocol (SLIP / PPP), etc., although customized or non-standard interface protocols may also be implemented.

[0099]

[0129] Information transferred through communication interface 440 is typically in the form of electrical communication signals 455. These signals 455 may be provided to communication interface 440 via communication channel 450 between communication interface 440 and external system 445. In one embodiment, communication channel 450 may be a wired or wireless network or any other type of communication link. Communication channel 450 transmits signals 455 and may be implemented using a variety of wired or wireless communication means, including wire or cable, optical fiber, conventional telephone line, cellular phone link, wireless data communication link, radio frequency (“RF”) link, or infrared link, to name just a few.

[0100]

[0130] Programs, including computer-executable instructions, and / or data are stored in main memory 415 and / or secondary memory 420. Programs and / or data may also be received from external systems 445 via communications interface 440 and stored in main memory 415 and / or secondary memory 420. The programs, when executed, may enable system 400 to perform one or more of the processes described herein.

[0101]

[0131] System 400 may include wireless communication components that facilitate wireless communication over a voice network and / or a data network (e.g., in the case of a mobile device such as a smartphone). The wireless communication components include an antenna system 470, a radio system 465, and a baseband system 460. In system 400, radio frequency (RF) signals are transmitted and received over the air by antenna system 470 under the control of radio system 465.

[0102]

[0132] In one embodiment, antenna system 470 may comprise one or more antennas and one or more multiplexers (not shown) that perform a switching function to provide transmit and receive signal paths for antenna system 470. In the receive path, the received RF signal may be coupled from the multiplexer to a low noise amplifier (not shown) that amplifies the received RF signal and transmits the amplified signal to radio system 465.

[0103]

[0133] In alternative embodiments, the radio system 465 may include one or more radios configured to communicate at various frequencies. In one embodiment, the radio system 465 may combine a demodulator (not shown) and a modulator (not shown) into a single integrated circuit (IC). The demodulator and modulator may also be separate components. In the receive path, the demodulator removes the RF carrier signal and transmits the remaining baseband received audio signal from the radio system 465 to the baseband system 460.

[0104]

[0134] If the received signal contains audio information, the baseband system 460 decodes and converts the signal to an analog signal. The signal is then amplified and sent to a speaker. The baseband system 460 also receives analog audio signals from a microphone. These analog audio signals are converted to digital signals and encoded by the baseband system 460. The baseband system 460 also encodes the digital signals for transmission and generates baseband transmit audio signals that are routed to a modulator portion of the radio system 465. The modulator mixes the baseband transmit audio signal with an RF carrier signal to generate an RF transmit signal, which is routed to the antenna system 470 and may pass through a power amplifier (not shown). The power amplifier amplifies the RF transmit signal and routes it to the antenna system 470, where the signal is switched to an antenna port for transmission.

[0105]

[0135] The baseband system 460 is communicatively coupled to the processor 410, which has access to memories 415 and 420. Thus, programs may be received from the baseband processor 460 and stored in the main memory 415 or the secondary memory 420, or executed upon receipt. Such programs, when executed, may enable the system 400 to perform one or more of the processes described herein.

[0106]

[0136] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles described herein may be applied to other embodiments without departing from the spirit or scope of the present invention. It should therefore be understood that the description and drawings presented herein represent presently preferred embodiments of the invention and, as such, are representative of the subject matter broadly contemplated by the present invention. It should further be understood that the scope of the present invention fully encompasses other embodiments that may become apparent to those skilled in the art, and that the scope of the present invention is not limited accordingly.

[0107]

[0137] As used herein, the terms "comprise" and "comprise" are open-ended. For example, "A comprises B" means that A can include either (i) B alone, or (ii) B in combination with one or more, potentially any number of, other components. In contrast, the term "consisting of" is closed-ended. For example, "A consists of B" means that A includes only B, with other components not being included in the same context.

[0108]

[0138] Combinations described herein, such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," and "A, B, C, or any combination thereof," include any combination of A, B, and / or C, and may include multiples of A, multiples of B, or multiples of C. Specifically, combinations such as "at least one of A, B, or C," "one or more of A, B, or C," "at least one of A, B, and C," "one or more of A, B, and C," "A, B, C, or any combination thereof" may be A only, B only, C only, A and B, A and C, B and C, A and B and C, and any such combination may include one or more members of its components A, B, and / or C. For example, a combination of A and B may include one A and multiple Bs, multiple A and one B, or multiple A and multiple Bs.

Claims

1. 1. A method comprising: using at least one hardware processor to create and maintain a first data structure in a shared memory for communicating data references to data in the shared memory from a sender to a receiver; The first data structure comprises: a first queue of said data references readable and writable by said sender and readable by said receiver; a first write index indicating a write position within the first queue, the first write index being readable and writable by the sender and readable by the receiver; a first read index indicating a read position within the first queue, the first read index being readable by the sender and readable and writable by the receiver.

2. Furthermore, by the sender, determining to send data to said recipient; reading the first read index; determining whether the first read index is valid; if determining that the first read index is invalid, switching to a safe state; and if determining that the first read index is valid, performing a write operation in the shared memory.

3. The write operation includes an enqueue operation, and the enqueue operation includes: adding a new data reference to the first queue at the write location indicated by the first write index; and updating the first write index.

4. The method of claim 3 , wherein updating the first write index comprises incrementing the first write index.

5. The write operation may further include, before performing the enqueue operation: writing at least one data item to a data area of ​​said shared memory; and obtaining a data reference to an address of the at least one data item within the data region of the shared memory as the new data reference to be added to the first queue in the enqueue operation.

6. The method of claim 2 , wherein the write operation includes modifying a data reference in the first queue.

7. The method of claim 2 further comprising repairing the first data structure in the safe state.

8. 8. The method of claim 7, further comprising generating and maintaining, by the sender, a redundant copy of the first data structure in a local memory of the sender, and wherein repairing the first data structure comprises restoring, by the sender, the first data structure from the redundant copy of the first data structure in the local memory of the sender.

9. The step of determining whether the first read index is valid comprises: reading the first write index; determining whether the first read index is greater than the first write index; determining that the first read index is valid if the first read index is not greater than the first write index; 3. The method of claim 2, further comprising: if determining that the first read index is greater than the first write index, determining that the first read index is invalid.

10. Further, by said recipient: reading the first write index; determining whether the first write index is valid; if determining that the first write index is invalid, switching to a safe state; and if determining that the first write index is valid, performing a read operation in the shared memory.

11. The read operation includes a dequeue operation, the dequeue operation comprising: reading at least one data reference from the first queue at the read location indicated by the first read index; and updating the first read index.

12. The method of claim 11 , wherein updating the first read index comprises incrementing the first read index.

13. The read operation further includes, after reading the at least one data reference from the first queue: determining whether said at least one data reference is valid; switching to a safe state if determining that the at least one data reference is invalid; and if determining that the at least one data reference is valid, reading data at an address referenced by the at least one data reference from a data region of the shared memory.

14. determining whether the at least one data reference is valid; determining whether the address referenced by the at least one data reference is within the data region of the shared memory; determining that the at least one data reference is valid if the address is determined to be within the data region of the shared memory; and determining that the at least one data reference is invalid if the address is determined not to be within the data region of the shared memory.

15. 14. The method of claim 13, further comprising repairing the first data structure in the safe state.

16. 16. The method of claim 15, further comprising generating and maintaining, by the recipient, a redundant copy of the first data structure in the recipient's local memory, and wherein repairing the first data structure comprises restoring, by the recipient, the first data structure from the redundant copy of the first data structure in the recipient's local memory.

17. and further comprising using said at least one hardware processor to create and maintain a second data structure in said shared memory for communicating data references to data in said shared memory from said recipient to said sender, said second data structure comprising: The second data structure comprises: a second queue of said data references readable and writable by said receiver and readable by said sender; a second write index indicating a write position within the second queue, the second write index being readable and writable by the receiver and readable by the sender; and a second read index indicating a read position within the second queue, the second read index being readable by the receiver and readable and writable by the sender.

18. and further comprising using said at least one hardware processor: transferring ownership of data in the shared memory from the sender to the receiver by the sender enqueuing a data reference to the data in the first queue of the first data structure; and returning ownership of the data in the shared memory from the recipient to the sender by the recipient enqueuing their data references to the data in the second queue of the second data structure.

19. The method of claim 1 , wherein the first queue and the first write index are not writable by the receiver, and the first read index is not writable by the sender.

20. The method of claim 1 , wherein the first queue and the first write index are writable by the receiver, and the first read index is writable by the sender.

21. at least one hardware processor; software configured to be executed by the at least one hardware processor to create and maintain data structures in the shared memory for communicating data references to data in the shared memory from senders to receivers; The data structure comprises: a queue of said data references readable and writable by said sender and readable by said receiver; a write index indicating a write position within the queue, the write index being readable and writable by the sender and readable by the receiver; a read index indicating a read position within the queue, the read index being readable by the sender and readable and writable by the receiver.

22. A non-transitory computer-readable medium having instructions stored thereon, the instructions being executed by a processor to cause the processor to: creating and maintaining a data structure in the shared memory for communicating data references to data in the shared memory from senders to receivers; The data structure comprises: a queue of data references readable and writable by the sender and readable by the receiver; a write index indicating a write position within the queue, the write index being readable and writable by the sender and readable by the receiver; a read index indicating a read position within the queue, the read index being readable by the sender and readable and writable by the receiver.

Images