## The Problem

Two processes need to communicate without copying data and without blocking locks. Standard C++ abstractions like `std::mutex` and `std::condition_variable` are bound to a single process's address space. However, concurrent access to shared data across process boundaries must still be safe and synchronized.

---

## How Shared Memory Works

Using `shm_open()` + `mmap()` maps the **same physical page frames** into multiple virtual address spaces. While virtual addresses differ between processes, the underlying physical memory is identical.

```
Process A (RW)              Physical Memory              Process B (RO)
──────────────              ───────────────              ──────────────
Virtual: 0x7f000000 ──────► Page Frame: 0x1234000 ◄────── Virtual: 0x6a000000
        (mmap r/w)            (same bytes)               (mmap r/o)

```

The CPU's Memory Management Unit (MMU) translates each process's virtual address to the exact same physical frame. All CPU cores—regardless of which process they are executing—operate on the same physical cache lines, maintaining cache coherence via hardware protocol (e.g., MESI).

---

## Why Lock-Free Atomics Work Across Processes

A lock-free `std::atomic<T>` stores its state strictly inside the memory location of `T` itself—it contains **no hidden pointers, no process-local state, and no mutexes**.

Because atomicity guarantees are provided by CPU hardware operating on physical cache lines, a lock-free `std::atomic<uint32_t>` in shared memory behaves identically whether accessed by multiple threads in one process or multiple processes entirely:

* **Reads and writes** are indivisible.
* **`std::memory_order`** guarantees visibility and instruction ordering across CPU cores/processes.

---

## The Three Fundamental Requirements

### 1. Lock-Free Guarantee

The atomic type must be guaranteed lock-free by hardware. If an atomic is *not* lock-free, the C++ runtime uses an internal fallback lock (often allocated on the process's private heap), making it completely inaccessible to other processes.

> [!WARNING] Verify at Compile Time
> Always check lock-free status at compile-time using `is_always_lock_free`:

```cpp
static_assert(std::atomic<uint32_t>::is_always_lock_free, "uint32_t must be lock-free");
static_assert(std::atomic<uint64_t>::is_always_lock_free, "uint64_t must be lock-free");

```

* **Supported:** Native integer types up to 64-bits on x86-64 and ARM64.
* **Not Supported:** Structs or types larger than the native register/double-word width (e.g., 128-bit on some platforms) are typically **not** lock-free.

---

### 2. Natural Alignment

The atomic variable must be naturally aligned in the shared memory struct layout. Unaligned or byte-packed access can span multiple cache lines, causing the hardware to lose atomicity guarantees.

```cpp
struct alignas(8) ShmLayout {
    std::atomic<uint32_t> head;   // 4-byte aligned — Correct
    std::atomic<uint32_t> tail;   // 4-byte aligned — Correct
};

static_assert(sizeof(std::atomic<uint32_t>) == 4);
static_assert(alignof(std::atomic<uint32_t>) == 4);

```

> [!TIP] Alignment Best Practice
> Avoid `#pragma pack(1)` or packing directives on shared memory structures containing atomic variables.

---

### 3. Same Physical Pages

Both processes must map the exact same file descriptor obtained via `shm_open()`. Mapping different handles or mapping mismatched offsets results in different physical pages, causing writes in Process A to be invisible to Process B.

```cpp
// Process A (Owner / Read-Write)
int fd = shm_open("/my_channel", O_CREAT | O_RDWR, 0600);
ftruncate(fd, sizeof(ShmLayout));

auto* shm = static_cast<ShmLayout*>(
    mmap(nullptr, sizeof(ShmLayout), PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0)
);

// Process B (Consumer / Read-Only)
int fd = shm_open("/my_channel", O_RDONLY, 0);

auto* shm = static_cast<ShmLayout*>(
    mmap(nullptr, sizeof(ShmLayout), PROT_READ, MAP_SHARED, fd, 0)
);
// shm->head and shm->tail refer to the exact same physical memory as in Process A

```

---

## Memory Ordering Across Processes

The C++ memory ordering semantics (`std::memory_order`) apply across process boundaries when operating on shared physical memory:

| Memory Order | Cross-Process Meaning |
| --- | --- |
| `memory_order_relaxed` | Indivisible read/write with **no** ordering guarantees relative to surrounding memory access. |
| `memory_order_release` (store) | All stores preceding this operation in Process A become visible to Process B upon an acquire load. |
| `memory_order_acquire` (load) | Prevents subsequent loads in Process B from being reordered before this atomic read. |
| `memory_order_seq_cst` | Establishes a globally consistent total order across all processes and threads. |

### Practical Producer-Consumer Pattern

```cpp
// Process A (Producer)
data_buffer[idx] = payload;                                       // 1. Write payload
shm->head.store(idx + 1, std::memory_order_release);             // 2. Publish (Release store)

// Process B (Consumer)
uint32_t h = shm->head.load(std::memory_order_acquire);          // 1. Acquire load
if (h > tail) {
    use(data_buffer[tail]);  // 2. Guaranteed to see payload written by Process A
}

```

---

## What Works vs. What Fails in Shared Memory

| Feature | Shared Memory Compatible? | Reason / Recommendation |
| --- | --- | --- |
| `std::atomic<T>` (Lock-Free) | **YES** | Stores value directly in SHM memory address; hardware handles synchronization. |
| Raw Pointers (`T*`) | **NO** | Virtual addresses differ per process. Use offsets (`uintptr_t` relative to SHM base) or `boost::interprocess::offset_ptr`. |
| `std::mutex` | **NO** | Standard library implementation contains process-local state. |
| `pthread_mutex_t` | **YES** *(With Caveat)* | Native POSIX mutexes work **if** initialized with `PTHREAD_PROCESS_SHARED`. |
| `std::condition_variable` | **NO** | Contains process-specific internal OS primitive state. |
| Modern Blocking (`std::atomic::wait`) | **YES** *(C++20)* | Under Linux (futex), `std::atomic::wait()` / `.notify_one()` works across processes for lock-free atomics in SHM. |

---

## Summary Rule

> [!SUCCESS] Practical Rule
> If **`std::atomic<T>::is_always_lock_free`** is `true` and `T` is **naturally aligned** in shared memory, concurrent reads and writes from multiple processes carry the exact same atomicity and memory ordering guarantees as multi-threaded access within a single process.

### Blocking Signaling Strategies

* **C++20 and newer:** Use `std::atomic::wait()` and `std::atomic::notify_one()` directly on your shared atomic variable.
* **C++11 to C++17:** Use POSIX named semaphores (`sem_open`, `sem_wait`, `sem_post`) or process-shared POSIX mutexes (`pthread_mutexattr_setpshared`).

---

## References

* [std::atomic::is_always_lock_free - cppreference](https://en.cppreference.com/w/cpp/atomic/atomic/is_always_lock_free)
* [POSIX shm_open - devdocs.io](https://www.google.com/search?q=https://devdocs.io/posix/functions/shm_open)

Atomic Operations Across Multiple Processes via Shared Memory

A **type trait** is typically a template that maps a type `T` to:

* A **compile-time boolean** (e.g., *"does $T$ satisfy some property?"*)
* Another **type** (e.g., *"strip references from $T$"*)

---

## Standard Library Foundation

In the Standard Library (`<type_traits>`), boolean traits are implemented using `std::true_type` and `std::false_type`, which derive from `std::bool_constant`:

```cpp
#include <type_traits>

using std::true_type;
using std::false_type;

// Conceptual underlying implementation:
template <bool B>
struct bool_constant {
    static constexpr bool value = B;
    constexpr operator bool() const noexcept { return value; }
};

using true_type  = bool_constant<true>;
using false_type = bool_constant<false>;

```

> [!INFO] Key Properties
> * `true_type::value` evaluates to `true`; `false_type::value` evaluates to `false`.
> * Objects of these types are implicitly convertible to `bool`, allowing syntax like `if constexpr (MyTrait())`.
> 
> 

### General Pattern for Custom Traits

1. Provide a **primary template** that defaults to `std::false_type`.
2. Provide **specializations** that inherit from `std::true_type` for matching target types.

---

## 1.1. Simple Concrete Example: `IsInt`

**Goal:** Create a trait `IsInt` that evaluates to `true` **only** for `int`, and `false` for everything else.

```cpp
#include <iostream>
#include <type_traits>

// Primary template: default to false
template <typename T>
struct IsInt : std::false_type {};

// Specialization: int is true
template <>
struct IsInt<int> : std::true_type {};

template <typename T>
void describe_type() {
    if constexpr (IsInt<T>()) {
        std::cout << "This is int\n";
    } else {
        std::cout << "This is NOT int\n";
    }
}

int main() {
    describe_type<int>();   // Prints: This is int
    describe_type<float>(); // Prints: This is NOT int
    return 0;
}

```

> [!NOTE] How `if constexpr` Works Here
> `if constexpr` evaluates `IsInt<T>()` at **compile time**. Only the matching branch is compiled into the binary; the unselected branch is completely discarded.

---

## 1.2. Advanced Scenario: Port Filtering

This pattern applies type traits to inspect and filter template parameter packs and tuples at compile time.

### 1. Defining the Trait

```cpp
// Primary template: default to false
template <class Tested_T>
struct SatisfiesDiagnosticServicePortConcept : std::false_type {};

// Positive specialization: matches diagnostic service ports
template <class ServiceData_T, diagnostic::types::ComponentId component_id_v>
struct SatisfiesDiagnosticServicePortConcept<
    diagnostic::to_aos::DiagnosticGatewayToSwco<ServiceData_T, component_id_v>
> : std::true_type {};

```

* For any type `T` not matching the template pattern, `value` is `false`.
* For types matching `diagnostic::to_aos::DiagnosticGatewayToSwco<ServiceData_T, component_id_v>`, `value` is `true`.

---

### 2. Filtering a Single Port

```cpp
template <class Port_T>
auto getDiagnosticServicePortOrEmpty(Port_T& port) {
    using InterfaceType = typename diagnostic::utils::SampleValueType<Port_T>::Type;

    if constexpr (SatisfiesDiagnosticServicePortConcept<InterfaceType>()) {
        // Keeps the port: returns std::tuple<Port_T&>
        return std::tuple<Port_T&>(port);
    } else {
        // Drops the port: returns std::tuple<>
        return std::tuple<>{};
    }
}

```

> [!SUCCESS] Compile-time Execution
> * `SatisfiesDiagnosticServicePortConcept<InterfaceType>()` is evaluated at compile time.
> * If true, the return type is `std::tuple<Port_T&>`.
> * If false, the return type is `std::tuple<>`.
> * Zero runtime overhead—only one branch is instantiated per `Port_T`.
> 
> 

---

### 3. Filtering an Entire Tuple

```cpp
template <typename PortTuple_T>
auto onlyDiagnosticServicePorts(const PortTuple_T& ports) {
    return std::apply(
        [](auto&... port) {
            // For each port, returns either:
            // - std::tuple<Port_T&> (1 element)
            // - std::tuple<>        (empty)
            return std::tuple_cat(getDiagnosticServicePortOrEmpty(port)...);
        },
        ports
    );
}

```

#### Breakdown:

1. **`std::apply`**: Unpacks `ports` into individual arguments passed to the lambda function parameter pack `port...`.
2. **Pack Expansion (`...`)**: Evaluates `getDiagnosticServicePortOrEmpty(port)` for each individual port in sequence.
3. **`std::tuple_cat`**: Concatenates all generated sub-tuples.
* Valid ports contribute `std::tuple<Port&>`.
* Invalid ports contribute `std::tuple<>` (ignored).


4. **Result**: A single flattened tuple containing only valid diagnostic service ports, maintaining original order.

---

## 1.3. Code Expansion Walkthrough

Given three ports:

```cpp
ServicePortType    p1;
NonServicePortType p2;
ServicePortType    p3;

auto ports = std::tie(p1, p2, p3);

```

When invoking `auto filtered = onlyDiagnosticServicePorts(ports);`, the compiler expands the function template as follows:

```cpp
auto onlyDiagnosticServicePorts(
    const std::tuple<ServicePortType&, NonServicePortType&, ServicePortType&>& ports
) {
    return std::apply(
        // 1. Lambda expands parameters:
        [](ServicePortType& p1, NonServicePortType& p2, ServicePortType& p3) {
            // 2. Pack expansion expands tuple_cat arguments:
            return std::tuple_cat(
                getDiagnosticServicePortOrEmpty(p1), // Returns std::tuple<ServicePortType&>
                getDiagnosticServicePortOrEmpty(p2), // Returns std::tuple<>
                getDiagnosticServicePortOrEmpty(p3)  // Returns std::tuple<ServicePortType&>
            );
        },
        ports
    );
}

```

---

## References & Useful Links

* [std::integral_constant - cppreference](https://devdocs.io/cpp/types/integral_constant)
* [A Quick Primer on Type Traits in Modern C++ - Internal Pointers](https://www.internalpointers.com/post/quick-primer-type-traits-modern-cpp)

$ whoami