Chapter 77: IPC: System V Shared Memory (shmget, shmat, shmdt, shmctl)

Chapter Objectives

By the end of this chapter, you will be able to:

• Understand the fundamental concepts of shared memory as a high-performance Inter-Process Communication (IPC) mechanism.
• Explain the architecture of System V shared memory within the Linux kernel and the roles of key data structures.
• Implement robust C programs that create, attach to, write to, read from, and detach from System V shared memory segments using the shmget, shmat, shmdt, and shmctl system calls.
• Manage the lifecycle of shared memory segments on a Linux system, including monitoring with ipcs and removal with ipcrm.
• Debug common issues related to permissions, key management, and synchronization in shared memory applications.
• Analyze the performance trade-offs of shared memory compared to other IPC mechanisms in the context of embedded systems.

Introduction

In the world of embedded Linux, performance is not a luxury; it is a fundamental requirement. From real-time data acquisition systems in industrial automation to the complex sensor fusion algorithms in autonomous drones, the ability for multiple processes to exchange data with minimal latency is critical. While the Linux kernel offers a rich variety of Inter-Process Communication (IPC) mechanisms, such as pipes and message queues, they all share a common limitation: data must be copied. The kernel acts as an intermediary, copying data from the address space of the sending process into kernel space, and then copying it again from kernel space to the address space of the receiving process. This double-copy operation, while safe and reliable, introduces overhead that can become a significant bottleneck in high-throughput applications.

This chapter introduces System V shared memory, a powerful and classic IPC technique that shatters this limitation. Shared memory allows two or more processes to map a common segment of physical memory directly into their own virtual address spaces. Once this mapping is established, the kernel steps out of the way. Data written by one process to the shared region is instantly visible to all other attached processes, with no copying and no kernel intervention required. This makes it the fastest form of IPC available on a Linux system. We will explore the “why” behind this performance, delving into the underlying kernel architecture that makes it possible. You will learn to wield the foundational system calls—shmget, shmat, shmdt, and shmctl—to build applications that leverage this raw speed. Using the Raspberry Pi 5 as our development platform, we will construct practical examples that demonstrate how to create, manage, and communicate through these shared memory segments, transforming abstract theory into tangible, high-performance code.

Technical Background

To truly appreciate the power and elegance of shared memory, we must first understand the problem it solves. In a modern multitasking operating system like Linux, each process operates within its own private, virtualized world. The kernel’s memory management unit (MMU) and virtual memory system work together to create a powerful illusion: that every process has exclusive access to the entire address space. This process isolation is a cornerstone of system stability and security. It prevents a misbehaving application from corrupting the memory of the kernel or other processes. However, this isolation fundamentally complicates communication. How can two processes, each confined to its own private memory sandbox, exchange information?

Most IPC mechanisms, like pipes or sockets, solve this by enlisting the kernel as a trusted intermediary. When Process A wants to send data to Process B, it executes a write() system call. This triggers a context switch, and the kernel copies the data from Process A’s user-space buffer into a protected kernel-space buffer. Later, when Process B is ready, it executes a read() system call. The kernel then copies the data from its internal buffer to Process B’s user-space buffer. This two-copy process is safe and robust but inherently introduces latency and consumes CPU cycles. For applications moving large volumes of data, such as processing high-resolution video frames or streaming sensor data, this overhead can be prohibitive.

The Shared Memory Paradigm

System V shared memory offers a radically different approach. Instead of copying data between processes, it arranges for processes to share the same data. The fundamental idea is to request that the kernel allocate a segment of physical RAM and then map this same segment into the virtual address space of multiple processes.

Imagine two people working in separate, soundproof offices (their process address spaces). To share a document using the traditional IPC method, one person would have to call a courier (the kernel), who would pick up the document (first copy), carry it to the other office, and deliver it (second copy). The shared memory approach is like placing a shared whiteboard in the hallway between the two offices. Both individuals can now look at and write on the same whiteboard. When one person writes a note, the other sees it instantly, with no courier needed. The kernel’s role is simply to set up the whiteboard initially and then get out of the way.

This direct access model is what makes shared memory exceptionally fast. Once the initial setup is complete, data exchange occurs at memory speed, limited only by the CPU’s ability to read from and write to RAM. The kernel is not involved in the data transfer itself, eliminating system call overhead and context switching for each transaction.

System V IPC Objects and Keys

System V IPC mechanisms, which also include semaphores and message queues, were introduced in the early days of UNIX and share a common identification scheme. Unlike files, which are identified by a path and filename, System V IPC objects are identified by a key of type key_t. This key is a simple integer that serves as a system-wide name for the IPC object.

Processes that wish to communicate must agree on a common key. This can be achieved by hardcoding a key value, but this is brittle and can lead to collisions with other applications. A more robust and conventional method is to use the ftok() (file to key) function. ftok() generates a key from two arguments: a path to an existing file and a project ID (an integer). As long as two processes provide the same file path and project ID, ftok() is guaranteed to return the same key, providing a reliable way for them to reference the same IPC object without hardcoding magic numbers.

The kernel maintains a system-wide data structure for each type of System V IPC object. For shared memory, there is a table of shmid_ds structures. Each time a new shared memory segment is created, the kernel allocates a new shmid_ds structure to store metadata about it, such as its size, permissions, and the process IDs of its creator and last operator. The key is the handle that user-space applications use to request access to one of these kernel-managed objects.

The Core System Calls

The API for System V shared memory consists of four primary system calls. Understanding the role of each is crucial to using them effectively.

shmget(): Get a Shared Memory Segment

The shmget() call is the entry point. Its purpose is to either create a new shared memory segment or obtain the identifier of an existing one.

int shmget(key_t key, size_t size, int shmflg);

• key: This is the key_t value, often generated by ftok(), that uniquely identifies the segment.
• size: This specifies the desired size of the memory segment in bytes. If you are creating a new segment, this value is mandatory. If you are accessing an existing segment, you can often pass 0, as the size is already defined.
• shmflg: This is a bitmask of flags that control the call’s behavior. The most important flags are:
  • IPC_CREAT: This flag tells the kernel to create a new segment if one with the given key does not already exist.
  • IPC_EXCL: This flag is used in conjunction with IPC_CREAT. It causes shmget() to fail if a segment with the given key already exists. Using IPC_CREAT | IPC_EXCL together provides a reliable, atomic way to ensure that you are the creator of a new segment and are not accidentally connecting to an old, stale one.
  • Permission bits (e.g., 0666): Just like file permissions, these bits (in octal) specify the read and write access for the owner, group, and others. For example, 0666 grants read and write permissions to everyone.

On success, shmget() returns a non-negative integer called the shared memory identifier (or shmid). This is not a pointer; it is a handle or an index into the kernel’s internal array of shared memory segments. This shmid is what you will use in subsequent calls to shmat(), shmdt(), and shmctl(). On failure, it returns -1 and sets errno.

shmat(): Attach the Segment to the Address Space

After obtaining a valid shmid from shmget(), the shared memory segment exists in the kernel, but it is not yet accessible to your process. You must “attach” it to your process’s virtual address space using shmat().

void *shmat(int shmid, const void *shmaddr, int shmflg);

• shmid: The identifier returned by a successful shmget() call.
• shmaddr: This argument allows you to suggest a virtual address where you would like the segment to be mapped. In modern Linux programming, this is almost always set to NULL, which lets the kernel choose a suitable, available address. This is the most portable and recommended practice.
• shmflg: A bitmask of flags. The most common are SHM_RDONLY to attach the segment in read-only mode, or 0 for read-write access (provided the segment’s permissions allow it).

On success, shmat() returns a void * pointer. This is the crucial return value: it is the starting virtual address of the shared memory segment within your process. You can now use this pointer just like any other pointer obtained from malloc(). You can read from it, write to it (if not read-only), and perform pointer arithmetic on it. On failure, it returns (void *) -1 and sets errno.

shmdt(): Detach the Segment

When a process is finished with a shared memory segment, it should detach it from its address space using shmdt().

int shmdt(const void *shmaddr);

• shmaddr: This must be the exact pointer returned by a previous successful call to shmat().

This call does not destroy the shared memory segment. It simply removes the mapping from the calling process’s virtual address space. The segment continues to exist in the kernel and can remain attached to other processes. Think of it as leaving the room with the shared whiteboard; the whiteboard itself remains. The segment is only marked for destruction when explicitly told to do so via shmctl().

shmctl(): Control the Segment

The shmctl() system call is the general-purpose control interface for shared memory segments. It is used to get status information, set metadata, and, most importantly, destroy a segment.

int shmctl(int shmid, int cmd, struct shmid_ds *buf);

• shmid: The identifier for the target segment.
• cmd: The command to perform. The three most common commands are:
  • IPC_STAT: Retrieves the shmid_ds structure for the segment and copies it into the buffer pointed to by buf. This allows you to query its size, permissions, attach count, etc.
  • IPC_SET: Modifies certain fields of the segment’s shmid_ds structure, using the values provided in buf. This can be used to change permissions, for example.
  • IPC_RMID: This is the crucial command for cleanup. It marks the segment for destruction.

The behavior of IPC_RMID is subtle but important. It does not immediately destroy the segment. Instead, it marks it as “to be destroyed”. The kernel will only actually deallocate the memory and remove the shmid_ds structure when the last process attached to the segment detaches from it (via shmdt() or process termination). This is a graceful mechanism that prevents a segment from being destroyed while other processes are still using it. A common and robust pattern is for the “server” or creator process to call shmctl with IPC_RMID immediately after creating the segment. This ensures that the segment will be automatically cleaned up by the kernel when all processes (including the creator) have terminated or detached, even if they crash unexpectedly.

%%{ init: { 'theme': 'base', 'themeVariables': { 'fontFamily': 'Open Sans' } } }%%
graph TD
    subgraph "Process A (Creator)"
        A1(<b>Start</b>) --> A2{"Generate Key<br><i>ftok(path, id)</i>"};
        A2 --> A3["shmget(key, size, <b>IPC_CREAT | IPC_EXCL</b>)"];
        A3 --> A4{Segment<br>Created?};
        A4 -- Yes --> A5["shmat(shmid, NULL, 0)"];
        A5 --> A6{Attached?<br>Returns shm_ptr};
        A6 -- Yes --> A7["<b>Write Data</b> to shm_ptr"];
        A7 --> A8["shmctl(shmid, <b>IPC_RMID</b>, NULL)<br><i>Mark for removal</i>"];
        A8 --> A9["shmdt(shm_ptr)<br><i>Detach</i>"];
        A9 --> A_END(<b>End</b>);
        A4 -- No --> A_FAIL[Handle shmget Error];
        A6 -- No --> A_FAIL2[Handle shmat Error];
    end

    subgraph "Linux Kernel (System V IPC Subsystem)"
        K1[shmid_ds structure allocated]
        K2[Memory Segment in RAM]
        K3["Segment marked 'dest'"]
        K4["nattch (attach count) decremented"]
        K5{nattch == 0 AND<br>marked 'dest'?}
        K6[<b>Deallocate Memory</b><br>Remove shmid_ds]
    end

    subgraph "Process B (User)"
        B1(<b>Start</b>) --> B2{"Generate Same Key<br><i>ftok(path, id)</i>"};
        B2 --> B3["shmget(key, size, 0666)"];
        B3 --> B4{Segment<br>Found?};
        B4 -- Yes --> B5["shmat(shmid, NULL, 0)"];
        B5 --> B6{Attached?<br>Returns shm_ptr};
        B6 -- Yes --> B7["<b>Read Data</b> from shm_ptr"];
        B7 --> B8["shmdt(shm_ptr)<br><i>Detach</i>"];
        B8 --> B_END(<b>End</b>);
        B4 -- No --> B_FAIL[Handle shmget Error];
        B6 -- No --> B_FAIL2[Handle shmat Error];
    end

    %% Styling
    style A1 fill:#1e3a8a,stroke:#1e3a8a,stroke-width:2px,color:#ffffff
    style B1 fill:#1e3a8a,stroke:#1e3a8a,stroke-width:2px,color:#ffffff
    style A_END fill:#10b981,stroke:#10b981,stroke-width:2px,color:#ffffff
    style B_END fill:#10b981,stroke:#10b981,stroke-width:2px,color:#ffffff
    style A_FAIL fill:#ef4444,stroke:#ef4444,stroke-width:1px,color:#ffffff
    style A_FAIL2 fill:#ef4444,stroke:#ef4444,stroke-width:1px,color:#ffffff
    style B_FAIL fill:#ef4444,stroke:#ef4444,stroke-width:1px,color:#ffffff
    style B_FAIL2 fill:#ef4444,stroke:#ef4444,stroke-width:1px,color:#ffffff
    style A4 fill:#f59e0b,stroke:#f59e0b,stroke-width:1px,color:#ffffff
    style A6 fill:#f59e0b,stroke:#f59e0b,stroke-width:1px,color:#ffffff
    style B4 fill:#f59e0b,stroke:#f59e0b,stroke-width:1px,color:#ffffff
    style B6 fill:#f59e0b,stroke:#f59e0b,stroke-width:1px,color:#ffffff
    style K5 fill:#f59e0b,stroke:#f59e0b,stroke-width:1px,color:#ffffff
    style A2 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style A3 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style A5 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style A7 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style A8 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style A9 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style B2 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style B3 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style B5 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style B7 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style B8 fill:#0d9488,stroke:#0d9488,stroke-width:1px,color:#ffffff
    style K1 fill:#8b5cf6,stroke:#8b5cf6,stroke-width:1px,color:#ffffff
    style K2 fill:#8b5cf6,stroke:#8b5cf6,stroke-width:1px,color:#ffffff
    style K3 fill:#8b5cf6,stroke:#8b5cf6,stroke-width:1px,color:#ffffff
    style K4 fill:#8b5cf6,stroke:#8b5cf6,stroke-width:1px,color:#ffffff
    style K6 fill:#8b5cf6,stroke:#8b5cf6,stroke-width:1px,color:#ffffff

    %% Connections
    A3 -- "Success (shmid)" --> K1
    K1 --> K2
    A5 -- "Attach" --> K2
    B5 -- "Attach" --> K2
    A8 -- "Mark" --> K3
    A9 -- "Detach" --> K4
    B8 -- "Detach" --> K4
    K4 --> K5
    K5 -- "Yes" --> K6

The Synchronization Problem

The raw speed of shared memory comes with a significant responsibility: synchronization. Because the kernel is not involved in data transfers, it provides no mechanism to prevent race conditions. If one process is in the middle of writing a complex data structure to shared memory, and another process tries to read it at the same time, the reader may see a partially updated, corrupted version of the data.

This is like one person erasing and rewriting a sentence on the shared whiteboard while the other person is trying to read it. They might read a nonsensical mix of the old and new sentences.

Therefore, any non-trivial use of shared memory requires an external synchronization mechanism. Processes must coordinate to ensure that one process has exclusive write access while others wait. The standard tools for this are semaphores or mutexes. While a deep dive into semaphores is a topic for another chapter, it is impossible to discuss shared memory responsibly without emphasizing that they are almost always used together. A typical pattern involves using a semaphore to act as a lock. A process must acquire the lock (the semaphore) before writing to shared memory and release it immediately after. Any reader must also acquire the same lock before reading. This ensures that read and write operations are atomic and data integrity is maintained.

Practical Examples

Now, let’s translate this theory into practice on our Raspberry Pi 5. We will create two programs: a “writer” that creates a shared memory segment and writes a message into it, and a “reader” that attaches to the same segment and reads the message.

Tip: You can compile these examples directly on your Raspberry Pi 5 if you have a development environment set up (e.g., gcc, make). Alternatively, you can cross-compile them on a more powerful host machine, which is a common workflow in professional embedded development.

Shared Header File (shm_common.h)

Since both our reader and writer need to agree on a key and a buffer size, it’s good practice to place these definitions in a common header file.

// shm_common.h

#ifndef SHM_COMMON_H
#define SHM_COMMON_H

#include <sys/types.h>

// We will use ftok to generate a key. This is the file that ftok will use.
// It must exist. We can create it with the `touch` command.
#define KEY_FILE_PATH "/tmp/shm_key_file"
#define PROJECT_ID 'X'

// The size of our shared memory segment
#define SHM_SIZE 1024

#endif // SHM_COMMON_H

The Writer Program (writer.c)

The writer’s job is to:

1. Generate a key using ftok().
2. Create a new shared memory segment using shmget().
3. Attach the segment to its address space using shmat().
4. Write a message into the shared memory.
5. Detach the segment using shmdt().

// writer.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <unistd.h>
#include "shm_common.h"

int main() {
    int shmid;
    key_t key;
    char *shm_ptr;
    const char *message = "Hello from the writer process!";

    // 1. Generate a unique key
    key = ftok(KEY_FILE_PATH, PROJECT_ID);
    if (key == -1) {
        perror("ftok");
        exit(EXIT_FAILURE);
    }
    printf("Writer: Generated key: %d\n", key);

    // 2. Create the shared memory segment.
    // IPC_CREAT: Create the segment if it doesn't exist.
    // 0666: Read/write permissions for owner, group, and others.
    shmid = shmget(key, SHM_SIZE, IPC_CREAT | 0666);
    if (shmid == -1) {
        perror("shmget");
        exit(EXIT_FAILURE);
    }
    printf("Writer: Shared memory segment created with ID: %d\n", shmid);

    // 3. Attach the segment to our data space.
    // The second argument (shmaddr) is NULL, so the kernel chooses the address.
    shm_ptr = (char *)shmat(shmid, NULL, 0);
    if (shm_ptr == (void *)-1) {
        perror("shmat");
        exit(EXIT_FAILURE);
    }
    printf("Writer: Shared memory attached at address: %p\n", shm_ptr);

    // 4. Write data into the shared memory.
    printf("Writer: Writing message to shared memory...\n");
    strncpy(shm_ptr, message, SHM_SIZE);
    shm_ptr[strlen(message)] = '\0'; // Ensure null termination

    printf("Writer: Message written. Waiting for reader...\n");
    // In a real application, you'd use a semaphore or other signal here.
    // For this simple example, we'll just sleep to give the reader time to run.
    sleep(10);

    // 5. Detach the shared memory segment.
    if (shmdt(shm_ptr) == -1) {
        perror("shmdt");
        exit(EXIT_FAILURE);
    }
    printf("Writer: Shared memory detached.\n");

    // 6. Mark the segment for removal.
    // This is important for cleanup. The segment will be removed once the
    // last process (the reader, in this case) detaches.
    if (shmctl(shmid, IPC_RMID, NULL) == -1) {
        perror("shmctl(IPC_RMID)");
        exit(EXIT_FAILURE);
    }
    printf("Writer: Shared memory segment marked for removal.\n");

    return 0;
}

The Reader Program (reader.c)

The reader’s job is simpler:

1. Generate the same key using ftok().
2. Get the ID of the existing segment using shmget().
3. Attach the segment using shmat().
4. Read and print the message.
5. Detach the segment using shmdt().

// reader.c

#include <stdio.h>
#include <stdlib.h>
#include <sys/ipc.h>
#include <sys/shm.h>
#include <unistd.h>
#include "shm_common.h"

int main() {
    int shmid;
    key_t key;
    char *shm_ptr;

    // 1. Generate the same key as the writer.
    key = ftok(KEY_FILE_PATH, PROJECT_ID);
    if (key == -1) {
        perror("ftok");
        exit(EXIT_FAILURE);
    }
    printf("Reader: Generated key: %d\n", key);

    // 2. Locate the segment.
    // Note: We don't use IPC_CREAT here. We want to fail if the segment
    // doesn't already exist.
    shmid = shmget(key, SHM_SIZE, 0666);
    if (shmid == -1) {
        perror("shmget");
        fprintf(stderr, "Reader: Is the writer process running?\n");
        exit(EXIT_FAILURE);
    }
    printf("Reader: Located shared memory segment with ID: %d\n", shmid);

    // 3. Attach the segment to our data space.
    shm_ptr = (char *)shmat(shmid, NULL, 0);
    if (shm_ptr == (void *)-1) {
        perror("shmat");
        exit(EXIT_FAILURE);
    }
    printf("Reader: Shared memory attached at address: %p\n", shm_ptr);

    // 4. Read data from the shared memory.
    printf("Reader: Reading from shared memory...\n");
    printf("Reader: Message received: \"%s\"\n", shm_ptr);

    // 5. Detach the shared memory segment.
    if (shmdt(shm_ptr) == -1) {
        perror("shmdt");
        exit(EXIT_FAILURE);
    }
    printf("Reader: Shared memory detached.\n");

    return 0;
}

Build, Flash, and Boot Procedures

Let’s compile and run these programs on the Raspberry Pi 5.

1. Connect to your Raspberry Pi 5:Use SSH to connect to your device.

ssh pi@<your_pi_ip_address>

2. Create the source files: On the Pi, use a text editor like nano or vim to create the three files: shm_common.h, writer.c, and reader.c. Copy and paste the code from above.

3. Create the key file:The ftok() function requires the file path it uses to exist.

touch /tmp/shm_key_file

4. Compile the programs:Use gcc to compile the writer and reader.

gcc -o writer writer.c -Wall
gcc -o reader reader.c -Wall


The -o flag specifies the output executable name, and -Wall enables all compiler warnings, which is a good practice.

5. Run the programs:You will need two separate terminal windows connected to your Pi.

In Terminal 1, run the writer:

./writer


You should see output like this:

Writer: Generated key: 1112361880
Writer: Shared memory segment created with ID: 1
Writer: Shared memory attached at address: 0x7f8c9d2000
Writer: Writing message to shared memory...
Writer: Message written. Waiting for reader...


The writer will now pause for 10 seconds.

In Terminal 2, quickly run the reader (while the writer is paused):

./reader


The reader’s output should be:

Reader: Generated key: 1112361880
Reader: Located shared memory segment with ID: 1
Reader: Shared memory attached at address: 0x7f9a4b1000
Reader: Reading from shared memory...
Reader: Message received: "Hello from the writer process!"
Reader: Shared memory detached.


Notice that the key and the segment ID match, but the attached address is different. This is expected and normal; each process gets its own virtual address mapping to the same physical memory.

Back in Terminal 1:After its 10-second sleep, the writer will finish its execution:

Writer: Shared memory detached.
Writer: Shared memory segment marked for removal.

Monitoring with ipcs

While the writer is running (during its sleep period), you can use the ipcs command in a third terminal to see the kernel’s view of the shared memory segment.

ipcs -m

The -m flag shows shared memory segments. The output will look something like this:

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x424c0158 1          pi         666        1024       2

Let’s break this down:

• key: The key we generated, shown in hexadecimal.
• shmid: The shared memory ID (1 in this case).
• owner: The user who created the segment (pi).
• perms: The permissions we set (666).
• bytes: The size of the segment (1024).
• nattch: Number of attaches. This is a crucial field for debugging. Here it is 2, because both the writer and the reader are attached.
• status: This will be blank normally. If the segment was marked for removal but still attached, it might show dest.

After both processes have finished, if you run ipcs -m again, the segment should be gone. This confirms that our IPC_RMID call worked correctly. If a segment is left behind, you can manually remove it using ipcrm.

# To remove a segment by its ID
ipcrm shm <shmid>

# Example:
ipcrm shm 1

Warning: Manually removing a shared memory segment that is still in use by a program can cause that program to crash with a segmentation fault when it next tries to access the invalid memory address. Use ipcrm with care.

Common Mistakes & Troubleshooting

System V shared memory is powerful, but its low-level nature can lead to several common pitfalls. Understanding these in advance can save hours of debugging.

Exercises

1. Passing Structured Data:
   • Objective: Modify the reader/writer programs to exchange a C struct instead of a simple string.
   • Guidance:
     1. In shm_common.h, define a struct (e.g., struct SensorData { int sensor_id; double value; char status[16]; };).
     2. Update SHM_SIZE to be sizeof(struct SensorData).
     3. In writer.c, after attaching, cast the shm_ptr to your struct type: struct SensorData *data = (struct SensorData *)shm_ptr;.
     4. Populate the struct fields: data->sensor_id = 101; data->value = 98.6; strcpy(data->status, "OK");.
     5. In reader.c, perform the same cast and then print the values of the individual struct members.
   • Verification: The reader should print the exact values for sensor_id, value, and status that the writer set.
2. Two-Way Communication:
   • Objective: Implement a simple two-way “ping-pong” communication.
   • Guidance:
     1. Modify the writer to write a “ping” message and then wait.
     2. Modify the reader to read the “ping”, overwrite it with a “pong” message in the same shared memory, and then exit.
     3. The writer, after waking from its wait, should read the memory again and verify it contains “pong”.
   • Challenge: How do you know when the reader has written its response? This exercise highlights the need for synchronization. A simple sleep() can work for a demo, but what is the “correct” way to solve this? (Hint: Semaphores).
3. Performance Measurement:
   • Objective: Roughly measure the time it takes to transfer a large amount of data using shared memory.
   • Guidance:
     1. Increase SHM_SIZE to a large value, for example, 10 megabytes (10 * 1024 * 1024).
     2. In the writer, use clock_gettime() with CLOCK_MONOTONIC to record the time just before you write to the memory (e.g., with a memcpy or a loop) and just after.
     3. Calculate and print the elapsed time and the resulting data transfer rate (in MB/s).
     4. (Advanced) Compare this to the time it takes to write the same amount of data through a pipe. You will see a dramatic difference.
4. Error Handling and Robustness:
   • Objective: Make the reader program more robust to failure conditions.
   • Guidance:
     1. Run the reader before running the writer. Observe how shmget() fails. The error message should be “No such file or directory”.
     2. Run the writer, but kill it with Ctrl+C before it has a chance to call shmctl with IPC_RMID.
     3. Use ipcs -m to confirm the segment is still present with nattch as 0.
     4. Modify the writer program so that if it gets an EEXIST error on shmget(key, size, IPC_CREAT | IPC_EXCL), it assumes a previous run crashed. It should then try to get the ID of the old segment, remove it with shmctl(old_shmid, IPC_RMID, NULL), and then try creating its new segment again. This makes the writer self-healing from previous crashes.

Summary

• High-Performance IPC: System V shared memory is the fastest form of IPC on Linux because it eliminates kernel-mediated data copying. Once a segment is mapped, data is transferred directly between process address spaces at memory speed.
• Core API: Communication is managed by four key system calls: shmget (create/get segment ID), shmat (attach segment to address space), shmdt (detach segment), and shmctl (control/destroy segment).
• Identification: Segments are identified system-wide by a key_t key, which is conventionally generated using the ftok() function to avoid hardcoded values.
• Lifecycle Management: A segment exists in the kernel from a successful shmget() call until it is explicitly marked for removal with shmctl(shmid, IPC_RMID, NULL) and the last process has detached from it.
• Synchronization is Mandatory: The kernel provides no implicit synchronization. To prevent race conditions and data corruption, you must use an external mechanism like semaphores or mutexes to coordinate access to the shared memory.
• Cleanup is Critical: Failing to remove unused shared memory segments leads to resource leaks. The best practice is for the creator to mark the segment for removal (IPC_RMID) immediately after creation to ensure automatic cleanup.

Further Reading

1. Linux man-pages: The official documentation is the ultimate authority.
   • man shmget
   • man shmat
   • man shmctl
   • man ftok
   • man ipcs
   • man ipcrm
2. The Linux Programming Interface by Michael Kerrisk: An exhaustive and highly respected reference for all Linux system programming. Chapters 45-48 provide an excellent deep dive into System V IPC.
3. Advanced Programming in the UNIX Environment by W. Richard Stevens and Stephen A. Rago: The classic text on UNIX system calls. While older, its explanation of the concepts behind IPC is timeless and clear.
4. POSIX Standard for Shared Memory: For a more modern, portable approach, reading the POSIX shared memory specification (shm_open, mmap) provides an interesting comparison and is often preferred in new development. You can find it on the Open Group’s website.
5. Beej’s Guide to Unix Interprocess Communication: A friendly, practical online guide that covers shared memory and other IPC mechanisms in an accessible style.