← C

Inter-Process Communication (APUE)

← Inter-Process Communication (APUE)

Select a question from the sidebar

15 questions in this topic

Question 1 / 15

How does the pipe() system call work for anonymous pipes?

pipe() creates an anonymous (unnamed) unidirectional communication channel between related processes.

Prototype:

#include <unistd.h>
int pipe(int pipefd[2]);

pipefd[0] is the read end, pipefd[1] is the write end.

Properties:

Unidirectional: data flows from pipefd[1] to pipefd[0]
Buffered in the kernel (typically 64KB on Linux)
FIFO (first-in-first-out) byte stream
No message boundaries (unlike message queues)

Blocking behavior:

read() on empty pipe blocks until data is available (or all write ends are closed -> returns 0 = EOF)
write() on full pipe blocks until space is available (or all read ends are closed -> SIGPIPE)

Typical usage: Create pipe, fork, parent and child each close the end they do not use.

SIGPIPE: If a process writes to a pipe with no readers, SIGPIPE is delivered (default action: terminate). The write returns -1 with errno = EPIPE.

Pseudo Code

1. pipe(pipefd) -- creates read end [0] and write end [1]
2. fork()
3. Parent: close(pipefd[0]), write to pipefd[1], close(pipefd[1])
4. Child:  close(pipefd[1]), read from pipefd[0], close(pipefd[0])
5. read returns 0 when all write ends are closed (EOF)
6. write to pipe with no readers -> SIGPIPE

Code

#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <sys/wait.h>

int main(void) {
    int pipefd[2];
    if (pipe(pipefd) == -1) {
        perror("pipe");
        return 1;
    }

    pid_t pid = fork();
    if (pid == -1) { perror("fork"); return 1; }

    if (pid == 0) {
        /* Child: read from pipe */
        close(pipefd[1]);  /* close unused write end */
        char buf[256];
        ssize_t n;
        while ((n = read(pipefd[0], buf, sizeof(buf) - 1)) > 0) {
            buf[n] = '\0';
            printf("Child received: %s", buf);
        }
        /* n == 0 means parent closed write end (EOF) */
        close(pipefd[0]);
        _exit(0);
    }

    /* Parent: write to pipe */
    close(pipefd[0]);  /* close unused read end */
    const char *msgs[] = {"Hello\n", "from\n", "parent\n"};
    for (int i = 0; i < 3; i++)
        write(pipefd[1], msgs[i], strlen(msgs[i]));
    close(pipefd[1]);  /* signals EOF to child */

    wait(NULL);
    return 0;
}

Child received: Hello
Child received: from
Child received: parent

Key Points

•pipe() creates pipefd[0] (read) and pipefd[1] (write)
•Unidirectional byte stream with kernel buffer (~64KB on Linux)
•Close unused ends after fork to avoid deadlock and to signal EOF
•read returns 0 (EOF) when all write ends are closed
•Writing to a pipe with no readers sends SIGPIPE

Gotchas

•Forgetting to close unused pipe ends causes deadlocks (reader waits forever for EOF)
•Writes up to PIPE_BUF bytes (typically 4096) are guaranteed atomic
•Pipes are only between related processes (parent-child via fork)
•pipe2() on Linux supports O_NONBLOCK and O_CLOEXEC flags

pipe(fd) creates a unidirectional channel: fd[0] = read, fd[1] = write. Use with fork(). Close unused ends. Read returns 0 when all write ends close. Writes to pipe with no readers -> SIGPIPE.

•fd[0] = read, fd[1] = write
•Close unused ends after fork

#include <unistd.h>
#include <sys/wait.h>
#include <string.h>

int main(void) {
    int fd[2];
    pipe(fd);
    if (fork() == 0) {
        close(fd[1]);
        char buf[64];
        ssize_t n = read(fd[0], buf, 64);
        write(STDOUT_FILENO, buf, n);
        _exit(0);
    }
    close(fd[0]);
    write(fd[1], "hello\n", 6);
    close(fd[1]);
    wait(NULL);
    return 0;
}

hello

Forgetting to close write end in reader prevents EOF detection

Question 2 / 15

How do you connect pipes between processes to create a pipeline (like ls | sort)?

A shell pipeline like ls | sort connects stdout of one process to stdin of the next using pipes and dup2().

Steps for cmd1 | cmd2:

Create a pipe: pipe(pipefd)
Fork child 1 (cmd1):
- Close read end: close(pipefd[0])
- Redirect stdout to pipe write end: dup2(pipefd[1], STDOUT_FILENO)
- Close original write end: close(pipefd[1])
- exec(cmd1)
Fork child 2 (cmd2):
- Close write end: close(pipefd[1])
- Redirect stdin to pipe read end: dup2(pipefd[0], STDIN_FILENO)
- Close original read end: close(pipefd[0])
- exec(cmd2)
Parent closes both pipe ends
Parent waits for both children

The order of dup2 and close is critical: dup2 first, then close the original fd (unless it equals the target fd).

Pseudo Code

pipe(pfd)
fork child1:
  close(pfd[0])                  // don't need read end
  dup2(pfd[1], STDOUT_FILENO)    // stdout -> pipe write
  close(pfd[1])                  // close duplicate
  exec(cmd1)

fork child2:
  close(pfd[1])                  // don't need write end
  dup2(pfd[0], STDIN_FILENO)     // stdin -> pipe read
  close(pfd[0])                  // close duplicate
  exec(cmd2)

parent:
  close(pfd[0]); close(pfd[1])  // close both ends
  wait for child1; wait for child2

Code

#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

/* Implements: ls /tmp | sort */
int main(void) {
    int pipefd[2];
    if (pipe(pipefd) == -1) { perror("pipe"); return 1; }

    /* Child 1: ls /tmp (stdout -> pipe) */
    pid_t pid1 = fork();
    if (pid1 == 0) {
        close(pipefd[0]);  /* close read end */
        dup2(pipefd[1], STDOUT_FILENO);
        close(pipefd[1]);  /* close original after dup2 */
        execlp("ls", "ls", "/tmp", (char *)NULL);
        perror("exec ls");
        _exit(127);
    }

    /* Child 2: sort (stdin <- pipe) */
    pid_t pid2 = fork();
    if (pid2 == 0) {
        close(pipefd[1]);  /* close write end */
        dup2(pipefd[0], STDIN_FILENO);
        close(pipefd[0]);  /* close original after dup2 */
        execlp("sort", "sort", (char *)NULL);
        perror("exec sort");
        _exit(127);
    }

    /* Parent: close both pipe ends and wait */
    close(pipefd[0]);
    close(pipefd[1]);
    waitpid(pid1, NULL, 0);
    waitpid(pid2, NULL, 0);

    return 0;
}

Key Points

•dup2 redirects stdout/stdin to pipe ends
•Close unused ends in each process to ensure EOF propagation
•Parent must close BOTH pipe ends (otherwise readers never get EOF)
•Close the original fd after dup2 (it is now a duplicate)
•For longer pipelines, repeat with multiple pipes

Gotchas

•Parent must close both pipe fds or the reading child never gets EOF
•If dup2 target equals the fd, it is a no-op -- handle if pipefd could be 0 or 1
•For N-command pipeline, you need N-1 pipes
•If child 1 produces output faster than child 2 consumes, pipe buffer fills and child 1 blocks

For cmd1 | cmd2: create pipe, fork child1 (dup2 stdout->pipe write), fork child2 (dup2 stdin->pipe read), close all pipe ends in parent and children, exec both commands.

•dup2 redirects stdout/stdin
•Close all pipe ends in parent

#include <unistd.h>
#include <sys/wait.h>

int main(void) {
    int pfd[2];
    pipe(pfd);
    if (fork() == 0) {
        close(pfd[0]);
        dup2(pfd[1], 1); close(pfd[1]);
        execlp("ls", "ls", (char*)NULL);
    }
    if (fork() == 0) {
        close(pfd[1]);
        dup2(pfd[0], 0); close(pfd[0]);
        execlp("sort", "sort", (char*)NULL);
    }
    close(pfd[0]); close(pfd[1]);
    wait(NULL); wait(NULL);
    return 0;
}

Not closing parent's pipe ends prevents EOF in reading child

Question 3 / 15

How do popen() and pclose() work for simple shell pipelines?

popen() combines pipe(), fork(), and exec("/bin/sh") into one convenient function. It runs a shell command and provides a FILE* stream to read its output or write to its input.

Prototype:

#include <stdio.h>
FILE *popen(const char *command, const char *type);
int pclose(FILE *stream);

type = "r": read from the command's stdout
type = "w": write to the command's stdin

How it works internally:

Creates a pipe
Forks a child
Child: redirects pipe to stdin or stdout, exec("/bin/sh", "-c", command)
Parent: returns a FILE* connected to the other end of the pipe

pclose():

Closes the FILE* stream
Calls waitpid() to collect the child's exit status
Returns the exit status (like wait()) or -1 on error

Warning: Like system(), popen() uses the shell, so it is vulnerable to shell injection with unsanitized input.

Pseudo Code

popen("ls -la", "r"):
  pipe(fd)
  fork()
  child: dup2(fd[1], STDOUT), exec("/bin/sh", "-c", "ls -la")
  parent: return fdopen(fd[0], "r")

pclose(fp):
  fclose(fp)
  waitpid(child_pid, &status, 0)
  return status

Code

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

int main(void) {
    /* Read command output */
    FILE *fp = popen("ls -la /tmp 2>&1", "r");
    if (fp == NULL) {
        perror("popen");
        return 1;
    }

    char line[256];
    while (fgets(line, sizeof(line), fp) != NULL) {
        printf("OUTPUT: %s", line);
    }

    int status = pclose(fp);
    if (status == -1) {
        perror("pclose");
    } else {
        printf("Command exited with status %d\n", WEXITSTATUS(status));
    }

    /* Write to command's stdin */
    fp = popen("wc -l", "w");
    if (fp == NULL) { perror("popen"); return 1; }

    fprintf(fp, "line 1\n");
    fprintf(fp, "line 2\n");
    fprintf(fp, "line 3\n");

    status = pclose(fp);  /* closes write end -> wc sees EOF */
    /* wc prints "3" to stdout */

    return 0;
}

OUTPUT: [ls -la /tmp output]
Command exited with status 0
       3

Key Points

•popen combines pipe+fork+exec(/bin/sh) for convenience
•type "r" reads command output; "w" writes to command input
•pclose waits for the child and returns its exit status
•Returns a FILE* (buffered I/O) -- use fgets/fprintf/etc.
•Uses /bin/sh -c, so shell features (pipes, redirection) work

Gotchas

•popen uses the shell -- vulnerable to injection (same as system())
•Only one direction per popen call (read OR write, not both)
•pclose must be called (not fclose) to properly wait for the child
•The FILE* from popen should not be passed to other processes

popen(cmd, "r") runs a shell command and returns a FILE* to read its output. popen(cmd, "w") writes to its stdin. pclose() waits and returns exit status. Uses shell -- same injection risks as system().

•Convenience wrapper for pipe+fork+exec
•Use pclose, not fclose

#include <stdio.h>

int main(void) {
    FILE *fp = popen("ls /tmp", "r");
    char buf[256];
    while (fgets(buf, sizeof(buf), fp))
        printf("%s", buf);
    pclose(fp);
    return 0;
}

Shell injection risk -- do not pass user input

Question 4 / 15

What are FIFOs (named pipes), and how do they differ from anonymous pipes?

A FIFO (First In, First Out) or named pipe is a type of file in the filesystem that provides pipe-like communication between unrelated processes.

Creating a FIFO:

#include <sys/stat.h>
int mkfifo(const char *pathname, mode_t mode);

Or from the shell: mkfifo /tmp/myfifo

Key differences from anonymous pipes:

Feature	Anonymous Pipe	FIFO
Creation	`pipe()`	`mkfifo()`
Visibility	Only via inherited fds	Filesystem path
Relatedness	Parent-child only	Any processes
Persistence	Exists while open	File persists until deleted
Direction	Unidirectional	Unidirectional

Opening behavior:

open(fifo, O_RDONLY) blocks until a writer opens the other end
open(fifo, O_WRONLY) blocks until a reader opens the other end
open(fifo, O_RDONLY | O_NONBLOCK) returns immediately
open(fifo, O_WRONLY | O_NONBLOCK) fails with ENXIO if no reader

Common use: Client-server communication where client and server are separate programs. Also used in shell: cmd > /tmp/myfifo in one terminal, cat /tmp/myfifo in another.

Pseudo Code

Server:
  mkfifo("/tmp/server_fifo", 0666)
  fd = open("/tmp/server_fifo", O_RDONLY)  -- blocks until client opens
  read(fd, request, sizeof(request))
  close(fd)

Client:
  fd = open("/tmp/server_fifo", O_WRONLY)  -- blocks until server opens
  write(fd, request, sizeof(request))
  close(fd)

Code

#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <sys/wait.h>

#define FIFO_PATH "/tmp/demo_fifo"

int main(void) {
    /* Create FIFO (ignore EEXIST) */
    if (mkfifo(FIFO_PATH, 0666) == -1 && errno != EEXIST) {
        perror("mkfifo");
        return 1;
    }

    pid_t pid = fork();
    if (pid == 0) {
        /* Child: writer */
        int fd = open(FIFO_PATH, O_WRONLY);
        if (fd == -1) { perror("open writer"); _exit(1); }
        const char *msg = "Hello via FIFO!\n";
        write(fd, msg, strlen(msg));
        close(fd);
        _exit(0);
    }

    /* Parent: reader */
    int fd = open(FIFO_PATH, O_RDONLY);
    if (fd == -1) { perror("open reader"); return 1; }
    char buf[256];
    ssize_t n = read(fd, buf, sizeof(buf) - 1);
    if (n > 0) {
        buf[n] = '\0';
        printf("Received: %s", buf);
    }
    close(fd);

    wait(NULL);
    unlink(FIFO_PATH);  /* clean up */
    return 0;
}

Received: Hello via FIFO!

Key Points

•FIFOs have filesystem names -- unrelated processes can communicate
•mkfifo() creates the FIFO; open() by both sides establishes connection
•open blocks until the other end also opens (by default)
•Same pipe semantics: FIFO byte stream, SIGPIPE if no readers
•FIFO file persists after processes close it -- must unlink to remove

Gotchas

•Opening O_RDONLY blocks until a writer opens (and vice versa) -- can deadlock if single-threaded
•O_RDWR opens succeed immediately but defeat the blocking synchronization
•Multiple writers to the same FIFO can interleave (writes > PIPE_BUF are not atomic)
•The FIFO file must be unlinked manually -- it survives process termination

FIFOs (named pipes) are pipe-like files in the filesystem created with mkfifo(). Unlike anonymous pipes, unrelated processes can use them. Open blocks until both reader and writer are connected.

•Filesystem-visible pipe for unrelated processes
•open blocks until both ends are opened

#include <sys/stat.h>
#include <fcntl.h>
#include <unistd.h>

int main(void) {
    mkfifo("/tmp/myfifo", 0666);
    int fd = open("/tmp/myfifo", O_WRONLY);  /* blocks until reader */
    write(fd, "data\n", 5);
    close(fd);
    unlink("/tmp/myfifo");
    return 0;
}

FIFO file must be unlinked manually after use

Question 5 / 15

How do System V message queues work (msgget/msgsnd/msgrcv)?

System V message queues provide message-oriented IPC where messages are typed and can be selectively received.

Key functions:

#include <sys/msg.h>
int msgget(key_t key, int msgflg);  /* create/access queue */
int msgsnd(int msqid, const void *msgp, size_t msgsz, int msgflg);
ssize_t msgrcv(int msqid, void *msgp, size_t msgsz, long msgtyp, int msgflg);
int msgctl(int msqid, int cmd, struct msqid_ds *buf);  /* control */

Message structure:

struct msgbuf {
    long mtype;       /* message type (must be > 0) */
    char mtext[1];    /* message data (variable length) */
};

msgrcv() type selection:

msgtyp == 0: receive first message (any type)
msgtyp > 0: receive first message of type msgtyp
msgtyp < 0: receive first message with type <= |msgtyp| (lowest type first)

Key generation: ftok() generates an IPC key from a pathname and project ID.

Advantages over pipes: Message boundaries preserved, type-based selection, persistent until explicitly removed, no need for parent-child relationship.

Pseudo Code

1. key = ftok(pathname, proj_id)
2. msqid = msgget(key, IPC_CREAT | 0666)
3. Sender: fill msgbuf with mtype > 0 and data, msgsnd(msqid, &msg, datalen, 0)
4. Receiver: msgrcv(msqid, &msg, max_datalen, type, 0)
   - type=0: any message; type>0: specific type; type<0: lowest type <= |type|
5. Cleanup: msgctl(msqid, IPC_RMID, NULL)  -- remove queue

Code

#include <sys/msg.h>
#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/wait.h>

#define MSG_SIZE 256

struct message {
    long mtype;
    char mtext[MSG_SIZE];
};

int main(void) {
    /* Create message queue */
    key_t key = ftok("/tmp", 'A');
    int msqid = msgget(key, IPC_CREAT | 0666);
    if (msqid == -1) { perror("msgget"); return 1; }

    pid_t pid = fork();
    if (pid == 0) {
        /* Child: send messages */
        struct message msg;
        msg.mtype = 1;  /* type 1: request */
        snprintf(msg.mtext, MSG_SIZE, "Hello from child %d", getpid());
        msgsnd(msqid, &msg, strlen(msg.mtext) + 1, 0);

        msg.mtype = 2;  /* type 2: priority */
        snprintf(msg.mtext, MSG_SIZE, "Urgent message!");
        msgsnd(msqid, &msg, strlen(msg.mtext) + 1, 0);

        _exit(0);
    }

    wait(NULL);

    /* Parent: receive type 2 first (selective) */
    struct message msg;
    ssize_t n = msgrcv(msqid, &msg, MSG_SIZE, 2, 0);
    if (n != -1)
        printf("Type 2: %s\n", msg.mtext);

    n = msgrcv(msqid, &msg, MSG_SIZE, 0, 0);  /* any type */
    if (n != -1)
        printf("Any type: %s\n", msg.mtext);

    /* Remove queue */
    msgctl(msqid, IPC_RMID, NULL);
    return 0;
}

Type 2: Urgent message!
Any type: Hello from child 12346

Key Points

•Message queues preserve message boundaries (unlike pipes)
•Messages have types (long > 0) enabling selective receive
•ftok() generates IPC keys from pathname + project ID
•Queues persist in the kernel until IPC_RMID (survive process exit)
•msgrcv with type < 0 receives lowest type not exceeding |type|

Gotchas

•System V IPC resources persist after process exit -- must explicitly IPC_RMID
•ftok() uses the inode of the pathname -- deleting and recreating the file changes the key
•Message size limit (MSGMAX, typically 8192 bytes) and queue size limit (MSGMNB)
•ipcs -q shows queues; ipcrm -q msqid removes them (if a program forgot cleanup)

System V message queues: msgget() creates, msgsnd() sends typed messages, msgrcv() receives (with type selection). Persistent in kernel until msgctl(IPC_RMID). Use ftok() for keys.

•Typed messages with selective receive
•Persistent -- must IPC_RMID to clean up

#include <sys/msg.h>
#include <string.h>

struct msg { long mtype; char mtext[128]; };

int main(void) {
    int id = msgget(IPC_PRIVATE, 0666 | IPC_CREAT);
    struct msg m = { .mtype = 1 };
    strcpy(m.mtext, "hello");
    msgsnd(id, &m, strlen(m.mtext) + 1, 0);
    msgrcv(id, &m, 128, 1, 0);
    msgctl(id, IPC_RMID, NULL);
    return 0;
}

IPC resources survive process exit -- always clean up

Question 6 / 15

How does POSIX shared memory work with shm_open() and mmap()?

POSIX shared memory provides the fastest IPC mechanism because processes access the same physical memory pages directly (no kernel copying).

Steps:

shm_open() creates/opens a shared memory object (returns an fd)
ftruncate() sets the size of the shared memory
mmap() maps it into the process's address space
Read/write the mapped memory directly
munmap() unmaps it
shm_unlink() removes the named shared memory object

Prototypes:

#include <sys/mman.h>
#include <fcntl.h>
int shm_open(const char *name, int oflag, mode_t mode);
int shm_unlink(const char *name);

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
int munmap(void *addr, size_t length);

mmap protection flags: PROT_READ, PROT_WRITE, PROT_EXEC, PROT_NONE mmap sharing flags: MAP_SHARED (visible to other processes), MAP_PRIVATE (copy-on-write)

Synchronization: Shared memory has no built-in synchronization. Use POSIX semaphores, mutexes with PTHREAD_PROCESS_SHARED, or other mechanisms.

Pseudo Code

Writer:
1. fd = shm_open("/myshm", O_CREAT | O_RDWR, 0666)
2. ftruncate(fd, size)
3. ptr = mmap(NULL, size, PROT_WRITE, MAP_SHARED, fd, 0)
4. Write to ptr
5. munmap(ptr, size); close(fd)

Reader:
1. fd = shm_open("/myshm", O_RDONLY, 0)
2. ptr = mmap(NULL, size, PROT_READ, MAP_SHARED, fd, 0)
3. Read from ptr
4. munmap(ptr, size); close(fd)

Cleanup: shm_unlink("/myshm")

Code

#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <sys/wait.h>

#define SHM_NAME "/demo_shm"
#define SHM_SIZE 4096

int main(void) {
    /* Create shared memory */
    int fd = shm_open(SHM_NAME, O_CREAT | O_RDWR, 0666);
    if (fd == -1) { perror("shm_open"); return 1; }
    ftruncate(fd, SHM_SIZE);

    /* Map into address space */
    char *ptr = mmap(NULL, SHM_SIZE, PROT_READ | PROT_WRITE,
                     MAP_SHARED, fd, 0);
    if (ptr == MAP_FAILED) { perror("mmap"); return 1; }
    close(fd);  /* fd no longer needed after mmap */

    pid_t pid = fork();
    if (pid == 0) {
        /* Child: write to shared memory */
        snprintf(ptr, SHM_SIZE, "Hello from child %d!", getpid());
        munmap(ptr, SHM_SIZE);
        _exit(0);
    }

    wait(NULL);

    /* Parent: read from shared memory */
    printf("Shared memory: %s\n", ptr);

    munmap(ptr, SHM_SIZE);
    shm_unlink(SHM_NAME);
    return 0;
}

Shared memory: Hello from child 12346!

Key Points

•Fastest IPC: no kernel copy, direct memory access
•shm_open creates a shared memory object (like a file in /dev/shm)
•mmap with MAP_SHARED makes changes visible to all mappers
•ftruncate sets the size; close(fd) is OK after mmap
•Requires external synchronization (semaphores, mutexes)

Gotchas

•Shared memory name must start with / and contain no other slashes
•shm_unlink only removes the name -- mapped memory persists until all processes unmap
•Compile with -lrt (link with librt) on some systems for shm_open
•Without synchronization, concurrent read/write is a data race (undefined behavior)

shm_open() creates shared memory, ftruncate() sizes it, mmap(MAP_SHARED) maps it. Fastest IPC (no copying). Needs external synchronization. Cleanup: munmap() + shm_unlink().

•Fastest IPC -- direct memory access
•Needs synchronization

#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

int main(void) {
    int fd = shm_open("/test", O_CREAT | O_RDWR, 0666);
    ftruncate(fd, 4096);
    char *p = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
    close(fd);
    strcpy(p, "hello");
    munmap(p, 4096);
    shm_unlink("/test");
    return 0;
}

Name must start with / and have no other slashes

Question 7 / 15

How do POSIX semaphores work (sem_init, sem_wait, sem_post)?

POSIX semaphores are counting synchronization primitives used to protect shared resources or signal between processes/threads.

Two types:

Named semaphores: Created with sem_open(), visible via filesystem name. Used between unrelated processes.
Unnamed semaphores: Created with sem_init(), placed in shared memory. Used between threads or related processes.

Key functions:

#include <semaphore.h>
int sem_init(sem_t *sem, int pshared, unsigned int value);
int sem_wait(sem_t *sem);     /* decrement; blocks if 0 */
int sem_trywait(sem_t *sem);  /* non-blocking */
int sem_post(sem_t *sem);     /* increment; wakes a waiter */
int sem_destroy(sem_t *sem);

sem_t *sem_open(const char *name, int oflag, mode_t mode, unsigned int value);
int sem_close(sem_t *sem);
int sem_unlink(const char *name);

sem_init pshared parameter:

pshared == 0: semaphore shared between threads of one process
pshared != 0: semaphore shared between processes (must be in shared memory)

Semaphore value semantics:

Value > 0: resources available, sem_wait decrements immediately
Value == 0: no resources, sem_wait blocks until another thread/process calls sem_post

Pseudo Code

Binary semaphore (mutex-like):
  sem_init(&sem, 0, 1)  -- value=1, one resource
  Thread A: sem_wait(&sem)  -- value becomes 0 (locked)
  Thread A: /* critical section */
  Thread A: sem_post(&sem)  -- value becomes 1 (unlocked)

Counting semaphore (bounded buffer):
  sem_init(&empty, 0, N)  -- N empty slots
  sem_init(&full, 0, 0)   -- 0 full slots
  Producer: sem_wait(&empty); produce; sem_post(&full)
  Consumer: sem_wait(&full);  consume; sem_post(&empty)

Code

#include <semaphore.h>
#include <pthread.h>
#include <stdio.h>
#include <unistd.h>

#define BUFFER_SIZE 5

static int buffer[BUFFER_SIZE];
static int in = 0, out = 0;
static sem_t empty, full;
static pthread_mutex_t mutex = PTHREAD_MUTEX_INITIALIZER;

void *producer(void *arg) {
    (void)arg;
    for (int i = 1; i <= 10; i++) {
        sem_wait(&empty);          /* wait for empty slot */
        pthread_mutex_lock(&mutex);
        buffer[in] = i;
        printf("Produced: %d\n", i);
        in = (in + 1) % BUFFER_SIZE;
        pthread_mutex_unlock(&mutex);
        sem_post(&full);           /* signal full slot */
    }
    return NULL;
}

void *consumer(void *arg) {
    (void)arg;
    for (int i = 0; i < 10; i++) {
        sem_wait(&full);           /* wait for full slot */
        pthread_mutex_lock(&mutex);
        int item = buffer[out];
        printf("Consumed: %d\n", item);
        out = (out + 1) % BUFFER_SIZE;
        pthread_mutex_unlock(&mutex);
        sem_post(&empty);          /* signal empty slot */
    }
    return NULL;
}

int main(void) {
    sem_init(&empty, 0, BUFFER_SIZE);  /* N empty slots */
    sem_init(&full, 0, 0);             /* 0 full slots */

    pthread_t prod, cons;
    pthread_create(&prod, NULL, producer, NULL);
    pthread_create(&cons, NULL, consumer, NULL);
    pthread_join(prod, NULL);
    pthread_join(cons, NULL);

    sem_destroy(&empty);
    sem_destroy(&full);
    return 0;
}

Produced: 1
Produced: 2
Produced: 3
Consumed: 1
Consumed: 2
Consumed: 3
Produced: 4
Produced: 5
Consumed: 4
Consumed: 5
Produced: 6
Produced: 7
Produced: 8
Consumed: 6
Consumed: 7
Consumed: 8
Produced: 9
Produced: 10
Consumed: 9
Consumed: 10

Key Points

•sem_wait decrements (blocks if 0); sem_post increments (wakes waiter)
•Named semaphores for unrelated processes; unnamed for threads/related processes
•pshared != 0 requires the semaphore to be in shared memory
•Counting semaphores track multiple resources (e.g., buffer slots)
•sem_post is async-signal-safe (can be called from signal handlers)

Gotchas

•Named semaphores persist until sem_unlink -- must clean up
•sem_wait can be interrupted by signals (returns -1, errno=EINTR) -- use a retry loop
•Destroying a semaphore while threads are waiting is undefined behavior
•On macOS, sem_init for unnamed semaphores is deprecated -- use sem_open instead

sem_wait() decrements (blocks if 0), sem_post() increments (wakes a waiter). Named (sem_open) for unrelated processes, unnamed (sem_init) for threads. Classic use: producer-consumer bounded buffer.

•sem_wait blocks if 0; sem_post wakes waiter
•Named semaphores persist -- must sem_unlink

#include <semaphore.h>
#include <stdio.h>

int main(void) {
    sem_t sem;
    sem_init(&sem, 0, 1);  /* binary semaphore, value=1 */
    sem_wait(&sem);         /* lock (value -> 0) */
    printf("critical section\n");
    sem_post(&sem);         /* unlock (value -> 1) */
    sem_destroy(&sem);
    return 0;
}

critical section

sem_wait can return EINTR -- use a retry loop

Question 8 / 15

How does memory-mapped file I/O work with mmap() and munmap()?

mmap() maps a file (or anonymous memory) into the process's virtual address space. Instead of using read()/write(), you access file contents through memory pointers.

Prototype:

void *mmap(void *addr, size_t length, int prot, int flags, int fd, off_t offset);
int munmap(void *addr, size_t length);
int msync(void *addr, size_t length, int flags);  /* flush to disk */

Protection flags: PROT_READ, PROT_WRITE, PROT_EXEC, PROT_NONE

Sharing flags:

MAP_SHARED -- changes visible to other processes and written to file
MAP_PRIVATE -- copy-on-write; changes not written to file
MAP_ANONYMOUS -- no file backing (pure memory allocation)

Advantages of mmap:

No explicit read/write calls (just pointer dereference)
Kernel manages page-in/page-out (demand paging)
Shared mappings between processes are efficient (same physical pages)
Random access without lseek

When to use:

Large files with random access patterns (databases)
Shared memory between processes
Fast file I/O (avoids double buffering)

Pseudo Code

1. fd = open(file, O_RDWR)
2. ptr = mmap(NULL, file_size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)
3. close(fd)  -- OK, mapping persists
4. Access ptr[0], ptr[100], etc. directly
5. Changes to ptr are written back to file (MAP_SHARED)
6. msync(ptr, size, MS_SYNC)  -- force flush to disk
7. munmap(ptr, size)  -- unmap

Anonymous mapping (no file):
  ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED|MAP_ANONYMOUS, -1, 0)
  (Used for shared memory between parent/child after fork)

Code

#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <sys/stat.h>

int main(void) {
    /* Create a file to map */
    int fd = open("mapped.dat", O_RDWR | O_CREAT | O_TRUNC, 0644);
    if (fd == -1) { perror("open"); return 1; }

    /* Set file size */
    size_t size = 4096;
    ftruncate(fd, (off_t)size);

    /* Map file into memory */
    char *map = mmap(NULL, size, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (map == MAP_FAILED) { perror("mmap"); return 1; }
    close(fd);  /* OK after mmap */

    /* Write to file via memory */
    strcpy(map, "Hello, mmap!");
    map[100] = 'X';  /* random access, no lseek needed */

    /* Force data to disk */
    msync(map, size, MS_SYNC);

    /* Read back */
    printf("Content: %s\n", map);
    printf("Byte at 100: %c\n", map[100]);

    munmap(map, size);

    /* Verify: read file normally */
    fd = open("mapped.dat", O_RDONLY);
    char buf[64];
    read(fd, buf, 63);
    buf[63] = '\0';
    printf("File content: %s\n", buf);
    close(fd);

    unlink("mapped.dat");
    return 0;
}

Content: Hello, mmap!
Byte at 100: X
File content: Hello, mmap!

Key Points

•mmap maps file contents into virtual memory (access via pointers)
•MAP_SHARED changes are written to file; MAP_PRIVATE is copy-on-write
•MAP_ANONYMOUS creates memory not backed by a file
•No read/write syscalls needed -- kernel handles page faults
•msync flushes changes to disk; munmap unmaps

Gotchas

•Accessing beyond the mapped size causes SIGBUS (not SIGSEGV)
•mmap length should be aligned to page size for optimal behavior
•MAP_SHARED requires write permission on the underlying file for PROT_WRITE
•truncating a file while mapped can cause SIGBUS on pages beyond new size

mmap() maps a file into memory. Access contents via pointers (no read/write calls). MAP_SHARED writes back to file. msync() flushes. munmap() cleans up.

•Access file via pointers, no read/write syscalls
•SIGBUS if accessing beyond file size

#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>

int main(void) {
    int fd = open("f.dat", O_RDWR | O_CREAT, 0644);
    ftruncate(fd, 4096);
    char *p = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);
    close(fd);
    strcpy(p, "hello mmap");
    munmap(p, 4096);
    return 0;
}

Accessing beyond mapped/file size causes SIGBUS

Question 9 / 15

How do Unix domain sockets (AF_UNIX) work for local IPC?

Unix domain sockets provide bidirectional communication between processes on the same host, using the socket API with filesystem paths instead of IP addresses.

Advantages over other IPC:

Bidirectional (unlike pipes)
Support both stream (SOCK_STREAM) and datagram (SOCK_DGRAM) modes
Can pass file descriptors between processes (SCM_RIGHTS)
Can pass credentials (SCM_CREDENTIALS on Linux)
Faster than TCP/IP loopback (no network stack overhead)

Address structure:

#include <sys/un.h>
struct sockaddr_un {
    sa_family_t sun_family;  /* AF_UNIX */
    char sun_path[108];      /* socket path */
};

Server pattern: socket() -> bind() -> listen() -> accept() -> read/write -> close Client pattern: socket() -> connect() -> read/write -> close

The socket path appears in the filesystem as a special file type (S_ISSOCK). Must be unlinked after use.

Pseudo Code

Server:
  fd = socket(AF_UNIX, SOCK_STREAM, 0)
  unlink(path)  -- remove stale socket file
  bind(fd, {AF_UNIX, path})
  listen(fd, backlog)
  client_fd = accept(fd)
  read/write on client_fd
  close(client_fd); close(fd); unlink(path)

Client:
  fd = socket(AF_UNIX, SOCK_STREAM, 0)
  connect(fd, {AF_UNIX, path})
  write/read on fd
  close(fd)

Code

#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <sys/wait.h>

#define SOCK_PATH "/tmp/demo.sock"

int main(void) {
    unlink(SOCK_PATH);  /* remove stale socket */

    pid_t pid = fork();
    if (pid == 0) {
        /* Child: client */
        sleep(1);  /* wait for server to start */
        int fd = socket(AF_UNIX, SOCK_STREAM, 0);
        struct sockaddr_un addr = { .sun_family = AF_UNIX };
        strncpy(addr.sun_path, SOCK_PATH, sizeof(addr.sun_path) - 1);

        if (connect(fd, (struct sockaddr *)&addr, sizeof(addr)) == -1) {
            perror("connect"); _exit(1);
        }
        write(fd, "Hello server!", 13);
        char buf[128];
        ssize_t n = read(fd, buf, sizeof(buf) - 1);
        if (n > 0) { buf[n] = '\0'; printf("Client got: %s\n", buf); }
        close(fd);
        _exit(0);
    }

    /* Parent: server */
    int sfd = socket(AF_UNIX, SOCK_STREAM, 0);
    struct sockaddr_un addr = { .sun_family = AF_UNIX };
    strncpy(addr.sun_path, SOCK_PATH, sizeof(addr.sun_path) - 1);

    bind(sfd, (struct sockaddr *)&addr, sizeof(addr));
    listen(sfd, 5);

    int cfd = accept(sfd, NULL, NULL);
    char buf[128];
    ssize_t n = read(cfd, buf, sizeof(buf) - 1);
    if (n > 0) {
        buf[n] = '\0';
        printf("Server got: %s\n", buf);
        write(cfd, "Hello client!", 13);
    }

    close(cfd);
    close(sfd);
    unlink(SOCK_PATH);
    wait(NULL);
    return 0;
}

Server got: Hello server!
Client got: Hello client!

Key Points

•AF_UNIX sockets provide bidirectional local IPC
•Faster than TCP loopback (no network stack)
•Can pass file descriptors between processes (SCM_RIGHTS)
•Socket path appears in filesystem, must be unlinked after use
•Support both stream (SOCK_STREAM) and datagram (SOCK_DGRAM)

Gotchas

•bind() fails with EADDRINUSE if the socket file already exists -- unlink first
•sun_path has a maximum length (typically 108 bytes including null)
•Socket file permissions are checked on connect (umask affects bind)
•Abstract sockets (Linux-specific, null byte prefix in sun_path) auto-clean up

Unix domain sockets (AF_UNIX) provide bidirectional local IPC using filesystem paths. Faster than TCP loopback. Can pass file descriptors. Use socket/bind/listen/accept/connect like TCP but with struct sockaddr_un.

•Bidirectional, faster than TCP loopback
•Must unlink socket file after use

#include <sys/socket.h>
#include <sys/un.h>
#include <unistd.h>

int main(void) {
    unlink("/tmp/test.sock");
    int fd = socket(AF_UNIX, SOCK_STREAM, 0);
    struct sockaddr_un a = { .sun_family = AF_UNIX };
    strncpy(a.sun_path, "/tmp/test.sock", 107);
    bind(fd, (struct sockaddr*)&a, sizeof(a));
    listen(fd, 5);
    /* accept, read, write... */
    close(fd); unlink("/tmp/test.sock");
    return 0;
}

bind fails if socket file exists -- unlink first

Question 10 / 15

How does the producer-consumer pattern work with shared memory and semaphores?

The producer-consumer pattern with shared memory and semaphores is a classic IPC problem where one process produces data and another consumes it via a shared buffer.

Components:

Shared memory: A circular buffer accessible to both processes
Semaphore empty: Counts empty slots (initialized to N)
Semaphore full: Counts full slots (initialized to 0)
Mutex semaphore: Protects concurrent access to buffer indices

Producer algorithm:

sem_wait(empty)    -- wait for empty slot
sem_wait(mutex)    -- lock buffer access
buffer[in] = item
in = (in + 1) % N
sem_post(mutex)    -- unlock
sem_post(full)     -- signal item available

Consumer algorithm:

sem_wait(full)     -- wait for item
sem_wait(mutex)    -- lock buffer access
item = buffer[out]
out = (out + 1) % N
sem_post(mutex)    -- unlock
sem_post(empty)    -- signal slot available

The semaphores ensure: producer blocks when buffer is full, consumer blocks when buffer is empty, and buffer access is mutually exclusive.

Pseudo Code

Shared data:
  buffer[N], in=0, out=0
  sem empty = N  (empty slots)
  sem full = 0   (full slots)
  sem mutex = 1  (mutual exclusion)

Producer:             Consumer:
  sem_wait(empty)       sem_wait(full)
  sem_wait(mutex)       sem_wait(mutex)
  buffer[in] = item     item = buffer[out]
  in = (in+1) % N       out = (out+1) % N
  sem_post(mutex)       sem_post(mutex)
  sem_post(full)        sem_post(empty)

Code

#include <sys/mman.h>
#include <semaphore.h>
#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <sys/wait.h>

#define BUF_SIZE 5
#define ITEMS 20

typedef struct {
    int buffer[BUF_SIZE];
    int in;
    int out;
    sem_t empty;
    sem_t full;
    sem_t mutex;
} shared_data_t;

int main(void) {
    /* Create shared memory for data + semaphores */
    shared_data_t *shm = mmap(NULL, sizeof(shared_data_t),
        PROT_READ | PROT_WRITE, MAP_SHARED | MAP_ANONYMOUS, -1, 0);
    shm->in = 0;
    shm->out = 0;
    sem_init(&shm->empty, 1, BUF_SIZE);  /* pshared=1 for processes */
    sem_init(&shm->full, 1, 0);
    sem_init(&shm->mutex, 1, 1);

    pid_t pid = fork();
    if (pid == 0) {
        /* Child: producer */
        for (int i = 1; i <= ITEMS; i++) {
            sem_wait(&shm->empty);
            sem_wait(&shm->mutex);
            shm->buffer[shm->in] = i;
            printf("Produced: %d\n", i);
            shm->in = (shm->in + 1) % BUF_SIZE;
            sem_post(&shm->mutex);
            sem_post(&shm->full);
        }
        _exit(0);
    }

    /* Parent: consumer */
    for (int i = 0; i < ITEMS; i++) {
        sem_wait(&shm->full);
        sem_wait(&shm->mutex);
        int item = shm->buffer[shm->out];
        printf("Consumed: %d\n", item);
        shm->out = (shm->out + 1) % BUF_SIZE;
        sem_post(&shm->mutex);
        sem_post(&shm->empty);
    }

    wait(NULL);
    sem_destroy(&shm->empty);
    sem_destroy(&shm->full);
    sem_destroy(&shm->mutex);
    munmap(shm, sizeof(shared_data_t));
    return 0;
}

Produced: 1
Consumed: 1
Produced: 2
Consumed: 2
...
Produced: 20
Consumed: 20

Key Points

•Three semaphores: empty (N), full (0), mutex (1)
•Producer waits on empty, posts full; consumer waits on full, posts empty
•Mutex protects buffer index updates
•Circular buffer with in/out indices
•sem_init with pshared=1 for inter-process semaphores

Gotchas

•sem_init pshared must be non-zero for cross-process semaphores
•Semaphores must be in shared memory (not on the stack) for inter-process use
•Deadlock if wait order on mutex and counting semaphore is swapped incorrectly
•On macOS, sem_init is deprecated -- use named semaphores with sem_open instead

Producer-consumer: shared circular buffer + 3 semaphores (empty=N, full=0, mutex=1). Producer: wait(empty), wait(mutex), produce, post(mutex), post(full). Consumer: wait(full), wait(mutex), consume, post(mutex), post(empty).

•3 semaphores: empty, full, mutex
•Circular buffer with modular arithmetic

#include <semaphore.h>

sem_t empty, full, mutex;
int buf[5], in = 0, out = 0;

void produce(int item) {
    sem_wait(&empty); sem_wait(&mutex);
    buf[in] = item; in = (in + 1) % 5;
    sem_post(&mutex); sem_post(&full);
}

int consume(void) {
    sem_wait(&full); sem_wait(&mutex);
    int item = buf[out]; out = (out + 1) % 5;
    sem_post(&mutex); sem_post(&empty);
    return item;
}

Semaphores must be in shared memory for cross-process use

Question 11 / 15

What are the trade-offs between different IPC mechanisms (speed, complexity, portability)?

Different IPC mechanisms suit different use cases:

Mechanism	Speed	Complexity	Portability	Direction	Message Boundary
Pipe	Medium	Low	Excellent	Unidirectional	No (byte stream)
FIFO	Medium	Low	Excellent	Unidirectional	No
Unix socket	Medium-High	Medium	Good	Bidirectional	Optional
Shared memory	Highest	High	Good (POSIX)	N/A (direct)	N/A
Message queue	Medium	Medium	Moderate (SysV)	Either	Yes
Semaphore	N/A (sync only)	Medium	Good (POSIX)	N/A	N/A
Signal	Lowest	Low	Excellent	Unidirectional	N/A

When to use what:

Pipes/FIFOs: Simple parent-child or command pipeline communication
Unix sockets: Client-server on same host, fd passing, bidirectional
Shared memory: Maximum performance, large data, random access (databases)
Message queues: Typed messages, decoupled producers/consumers
Semaphores: Synchronization (not data transfer)
Signals: Simple notifications, no data payload (except real-time)

System V vs POSIX IPC:

System V (msgget, shmget, semget): older, persistent, works everywhere
POSIX (mq_open, shm_open, sem_open): cleaner API, fd-based, better integration with select/poll

Pseudo Code

Decision tree:
  Need highest speed? -> Shared memory + semaphores
  Need message boundaries? -> Message queues or SOCK_DGRAM
  Need bidirectional? -> Unix domain sockets
  Simple parent-child stream? -> Pipe
  Unrelated processes, stream? -> FIFO or Unix socket
  Need fd passing? -> Unix domain socket (SCM_RIGHTS)
  Just notifications? -> Signals
  Need portability? -> Pipes and signals (most portable)

Code

#include <stdio.h>

/* This is a conceptual comparison -- no single runnable example */

/*
 * PIPE: simplest, parent-child only
 *   pipe(fd); fork(); read/write
 *
 * FIFO: named pipe, unrelated processes
 *   mkfifo("/tmp/fifo", 0666); open/read/write
 *
 * UNIX SOCKET: bidirectional, fd passing
 *   socket(AF_UNIX, SOCK_STREAM, 0); bind/connect/read/write
 *
 * SHARED MEMORY: fastest, needs synchronization
 *   shm_open + mmap + semaphores
 *
 * MESSAGE QUEUE: typed messages, decoupled
 *   mq_open/mq_send/mq_receive (POSIX)
 *   msgget/msgsnd/msgrcv (System V)
 */

int main(void) {
    printf("IPC Comparison:\n");
    printf("  Pipe:         Simple, unidirectional, parent-child\n");
    printf("  FIFO:         Named pipe, unrelated processes\n");
    printf("  Unix socket:  Bidirectional, fd passing\n");
    printf("  Shared mem:   Fastest, needs sync\n");
    printf("  Msg queue:    Typed messages, decoupled\n");
    printf("  Semaphore:    Synchronization only\n");
    printf("  Signal:       Notifications, minimal data\n");
    return 0;
}

IPC Comparison:
  Pipe:         Simple, unidirectional, parent-child
  FIFO:         Named pipe, unrelated processes
  Unix socket:  Bidirectional, fd passing
  Shared mem:   Fastest, needs sync
  Msg queue:    Typed messages, decoupled
  Semaphore:    Synchronization only
  Signal:       Notifications, minimal data

Key Points

•Shared memory is fastest (no kernel copy) but needs synchronization
•Pipes are simplest but unidirectional and parent-child only
•Unix sockets are the most flexible (bidirectional, fd passing)
•Message queues preserve message boundaries and support typed selection
•POSIX IPC (shm_open etc.) has cleaner API than System V (shmget etc.)

Gotchas

•Shared memory without proper synchronization leads to data races
•System V IPC resources persist after process exit -- must explicitly remove
•Pipes have limited buffer size (blocking on full buffer)
•Signals can be lost (standard signals not queued) -- poor for reliable communication

Shared memory = fastest (no copy). Pipes = simplest (unidirectional). Unix sockets = most flexible (bidirectional, fd passing). Message queues = typed messages. Choose based on speed needs, direction, and complexity budget.

•Shared memory = fastest; pipes = simplest; Unix sockets = most flexible
•POSIX IPC preferred over System V for new code

/* No single code example -- see individual IPC topics */
#include <stdio.h>
int main(void) {
    printf("Fastest: shared memory\n");
    printf("Simplest: pipe\n");
    printf("Most flexible: Unix domain socket\n");
    return 0;
}

Fastest: shared memory
Simplest: pipe
Most flexible: Unix domain socket

No single best IPC -- depends on use case

Question 12 / 15

How does record locking with fcntl() prevent concurrent file access issues?

fcntl record locking allows multiple processes to coordinate access to byte ranges within a file, preventing concurrent read/write conflicts.

Lock types:

F_RDLCK (shared/read): Multiple readers allowed, writers excluded
F_WRLCK (exclusive/write): Single writer, all others excluded
F_UNLCK: Release a lock

Compatibility matrix:

Existing	F_RDLCK request	F_WRLCK request
No lock	Granted	Granted
F_RDLCK	Granted	Blocked
F_WRLCK	Blocked	Blocked

Common pattern -- database-style locking:

Lock the record region (byte range)
Read/modify the data
Unlock the region

This is advisory locking -- processes that do not use fcntl locking can still read/write freely. All cooperating processes must agree to use locking.

Deadlock detection: The kernel detects deadlocks for F_SETLKW and returns EDEADLK instead of blocking forever.

Pseudo Code

Read operation:
  lock_region(fd, F_RDLCK, record_offset, record_size)
  read(fd, &record, sizeof(record))
  unlock_region(fd, record_offset, record_size)

Write operation:
  lock_region(fd, F_WRLCK, record_offset, record_size)
  read(fd, &record, sizeof(record))
  modify record
  lseek(fd, record_offset, SEEK_SET)
  write(fd, &record, sizeof(record))
  unlock_region(fd, record_offset, record_size)

Code

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>

typedef struct {
    int id;
    char name[32];
    double balance;
} record_t;

int lock_record(int fd, int type, int recnum) {
    struct flock fl;
    fl.l_type = (short)type;
    fl.l_whence = SEEK_SET;
    fl.l_start = (off_t)(recnum * (off_t)sizeof(record_t));
    fl.l_len = sizeof(record_t);
    return fcntl(fd, F_SETLKW, &fl);  /* blocking */
}

int unlock_record(int fd, int recnum) {
    return lock_record(fd, F_UNLCK, recnum);
}

void update_balance(int fd, int recnum, double amount) {
    /* Exclusive lock for write */
    if (lock_record(fd, F_WRLCK, recnum) == -1) {
        if (errno == EDEADLK)
            fprintf(stderr, "Deadlock detected!\n");
        return;
    }

    record_t rec;
    off_t offset = (off_t)(recnum * (off_t)sizeof(record_t));
    pread(fd, &rec, sizeof(rec), offset);
    rec.balance += amount;
    pwrite(fd, &rec, sizeof(rec), offset);

    unlock_record(fd, recnum);
}

int main(void) {
    int fd = open("accounts.db", O_RDWR | O_CREAT, 0644);
    if (fd == -1) { perror("open"); return 1; }

    /* Initialize a record */
    record_t rec = { .id = 1, .name = "Alice", .balance = 1000.0 };
    pwrite(fd, &rec, sizeof(rec), 0);

    /* Update with locking */
    update_balance(fd, 0, -50.0);

    /* Read with shared lock */
    lock_record(fd, F_RDLCK, 0);
    pread(fd, &rec, sizeof(rec), 0);
    printf("%s: $%.2f\n", rec.name, rec.balance);
    unlock_record(fd, 0);

    close(fd);
    unlink("accounts.db");
    return 0;
}

Alice: $950.00

Key Points

•fcntl byte-range locking coordinates multi-process file access
•F_RDLCK allows concurrent readers; F_WRLCK is exclusive
•F_SETLKW blocks until lock is available; F_SETLK returns immediately
•Kernel detects deadlocks (EDEADLK) for F_SETLKW
•Advisory locking only -- all processes must cooperate

Gotchas

•Closing ANY fd to the same file releases ALL your locks on it
•Locks are not inherited across fork (child has no locks)
•Advisory locks do not prevent non-cooperating processes from accessing the file
•pread/pwrite avoid the lseek+read/write race (thread-safe with locks)

fcntl byte-range locking: F_RDLCK for shared read, F_WRLCK for exclusive write. F_SETLKW blocks until available. Advisory only (cooperative). Kernel detects deadlocks (EDEADLK).

•F_RDLCK = shared; F_WRLCK = exclusive
•EDEADLK returned for detected deadlocks

#include <fcntl.h>
#include <unistd.h>

int main(void) {
    int fd = open("data.db", O_RDWR | O_CREAT, 0644);
    struct flock fl = { .l_type = F_WRLCK, .l_whence = SEEK_SET,
                        .l_start = 0, .l_len = 100 };
    fcntl(fd, F_SETLKW, &fl);  /* lock bytes 0-99 */
    /* ... write ... */
    fl.l_type = F_UNLCK;
    fcntl(fd, F_SETLK, &fl);   /* unlock */
    close(fd);
    return 0;
}

Closing any fd to the file releases all locks

Question 13 / 15

What are the differences between POSIX IPC and System V IPC?

Both POSIX and System V provide message queues, shared memory, and semaphores, but with different APIs and semantics.

System V IPC (older):

Message queues: msgget, msgsnd, msgrcv, msgctl
Shared memory: shmget, shmat, shmdt, shmctl
Semaphores: semget, semop, semctl
Uses integer keys (generated by ftok())
Resources persist in kernel until IPC_RMID
Status via ipcs command, cleanup via ipcrm
Semaphores are sets (array of counters)

POSIX IPC (newer):

Message queues: mq_open, mq_send, mq_receive, mq_close, mq_unlink
Shared memory: shm_open, mmap, munmap, shm_unlink
Semaphores: sem_open, sem_wait, sem_post, sem_close, sem_unlink
Uses named paths (like filenames, starting with /)
File-descriptor based (can use with select/poll)
Cleaner, more consistent API
Semaphores are individual counters

Key advantages of POSIX IPC:

FD-based: integrates with select(), poll(), epoll()
Simpler API with familiar open/close/unlink semantics
Named like files (easier to understand and manage)
Thread-safe by design

Pseudo Code

System V Shared Memory:
  key = ftok("/tmp", 'A')
  id = shmget(key, size, IPC_CREAT | 0666)
  ptr = shmat(id, NULL, 0)
  /* use ptr */
  shmdt(ptr)
  shmctl(id, IPC_RMID, NULL)

POSIX Shared Memory:
  fd = shm_open("/myshm", O_CREAT | O_RDWR, 0666)
  ftruncate(fd, size)
  ptr = mmap(NULL, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0)
  close(fd)
  /* use ptr */
  munmap(ptr, size)
  shm_unlink("/myshm")

Code

#include <stdio.h>
#include <string.h>

/* System V example */
#include <sys/shm.h>
void sysv_example(void) {
    key_t key = ftok("/tmp", 'S');
    int shmid = shmget(key, 1024, IPC_CREAT | 0666);
    char *ptr = (char *)shmat(shmid, NULL, 0);
    strcpy(ptr, "System V shared memory");
    printf("SysV: %s\n", ptr);
    shmdt(ptr);
    shmctl(shmid, IPC_RMID, NULL);
}

/* POSIX example */
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
void posix_example(void) {
    int fd = shm_open("/posix_shm", O_CREAT | O_RDWR, 0666);
    ftruncate(fd, 1024);
    char *ptr = (char *)mmap(NULL, 1024, PROT_READ | PROT_WRITE,
                             MAP_SHARED, fd, 0);
    close(fd);
    strcpy(ptr, "POSIX shared memory");
    printf("POSIX: %s\n", ptr);
    munmap(ptr, 1024);
    shm_unlink("/posix_shm");
}

int main(void) {
    sysv_example();
    posix_example();
    printf("\nPOSIX IPC: fd-based, cleaner API, select/poll compatible\n");
    printf("SysV IPC:  integer keys, persistent, works everywhere\n");
    return 0;
}

SysV: System V shared memory
POSIX: POSIX shared memory

POSIX IPC: fd-based, cleaner API, select/poll compatible
SysV IPC:  integer keys, persistent, works everywhere

Key Points

•POSIX IPC uses named paths and file descriptors; System V uses integer keys
•POSIX IPC integrates with select/poll (fd-based); System V does not
•Both persist until explicitly removed (unlink / IPC_RMID)
•POSIX has cleaner, more consistent API
•System V has wider legacy support on older systems

Gotchas

•System V semaphores are sets of counters; POSIX semaphores are individual counters
•POSIX message queues support mq_notify for async notification; System V does not
•On some systems, POSIX shared memory lives in /dev/shm; System V uses kernel tables
•Mixing POSIX and System V IPC in the same application is confusing and error-prone

POSIX IPC: named paths, fd-based (select/poll compatible), cleaner API. System V IPC: integer keys, older, wider legacy support. Both have message queues, shared memory, and semaphores. POSIX preferred for new code.

•POSIX: fd-based, cleaner; System V: key-based, older
•Prefer POSIX for new code

/* POSIX: fd-based, named */
#include <sys/mman.h>
#include <fcntl.h>
#include <unistd.h>
int fd = shm_open("/myshm", O_CREAT | O_RDWR, 0666);

/* System V: key-based */
#include <sys/shm.h>
int id = shmget(ftok("/tmp",'A'), 4096, IPC_CREAT | 0666);

Mixing POSIX and System V in one app is confusing

Question 14 / 15

What causes deadlocks in IPC, and how can they be prevented?

A deadlock occurs when two or more processes are waiting for each other to release resources, creating a cycle of dependencies.

Four necessary conditions (Coffman conditions):

Mutual exclusion: Resources are non-sharable
Hold and wait: Process holds one resource while waiting for another
No preemption: Resources cannot be forcibly taken
Circular wait: A cycle exists in the wait graph (A waits for B, B waits for A)

Common IPC deadlock scenarios:

Two processes each lock different records and then try to lock each other's record
Parent and child both write to the same pipe without reading (pipe buffer fills)
Two FIFOs opened in opposite order (both block on open)

Prevention strategies:

Lock ordering: Always acquire locks in the same global order (e.g., by resource number)
Timeout: Use non-blocking lock attempts with timeout
Try-lock: Use F_SETLK (non-blocking) and release all locks on failure, then retry
Single lock: Use one coarse-grained lock instead of multiple fine-grained ones
Deadlock detection: The kernel detects fcntl deadlocks (returns EDEADLK)

Lock ordering is the most practical and widely used strategy.

Pseudo Code

DEADLOCK:
  Process A: lock(record 1) -> lock(record 2)  // blocks waiting for B
  Process B: lock(record 2) -> lock(record 1)  // blocks waiting for A
  // Both blocked forever!

PREVENTION (lock ordering):
  Process A: lock(record 1) -> lock(record 2)  // always lock lower first
  Process B: lock(record 1) -> lock(record 2)  // same order!
  // Process B blocks on record 1, but A can proceed -> no deadlock

PREVENTION (try-lock):
  Process A: lock(record 1)
  Process A: trylock(record 2) -> EAGAIN
  Process A: unlock(record 1) -> retry later

Code

#include <fcntl.h>
#include <unistd.h>
#include <stdio.h>
#include <errno.h>

int try_lock(int fd, int type, off_t start, off_t len) {
    struct flock fl = { .l_type = (short)type, .l_whence = SEEK_SET,
                        .l_start = start, .l_len = len };
    if (fcntl(fd, F_SETLK, &fl) == -1) {
        if (errno == EAGAIN || errno == EACCES)
            return -1;  /* would block */
        perror("fcntl");
        return -1;
    }
    return 0;
}

void unlock(int fd, off_t start, off_t len) {
    struct flock fl = { .l_type = F_UNLCK, .l_whence = SEEK_SET,
                        .l_start = start, .l_len = len };
    fcntl(fd, F_SETLK, &fl);
}

/* Deadlock-free two-record lock using ordering */
int lock_two_records(int fd, off_t rec1, off_t rec2, off_t recsize) {
    /* Always lock the lower offset first */
    off_t first = (rec1 < rec2) ? rec1 : rec2;
    off_t second = (rec1 < rec2) ? rec2 : rec1;

    struct flock fl = { .l_type = F_WRLCK, .l_whence = SEEK_SET,
                        .l_start = first * recsize, .l_len = recsize };
    if (fcntl(fd, F_SETLKW, &fl) == -1) {
        if (errno == EDEADLK) {
            fprintf(stderr, "Deadlock detected by kernel\n");
            return -1;
        }
        return -1;
    }

    fl.l_start = second * recsize;
    if (fcntl(fd, F_SETLKW, &fl) == -1) {
        if (errno == EDEADLK) {
            /* Release first lock and retry */
            unlock(fd, first * recsize, recsize);
            return -1;
        }
        return -1;
    }

    return 0;  /* both locked */
}

int main(void) {
    int fd = open("data.db", O_RDWR | O_CREAT, 0644);
    if (fd == -1) { perror("open"); return 1; }

    /* Lock records 5 and 3 (ordered: 3 first, then 5) */
    if (lock_two_records(fd, 5, 3, 100) == 0) {
        printf("Both records locked (deadlock-free)\n");
        unlock(fd, 3 * 100, 100);
        unlock(fd, 5 * 100, 100);
    }

    close(fd);
    unlink("data.db");
    return 0;
}

Both records locked (deadlock-free)

Key Points

•Deadlock requires all four Coffman conditions simultaneously
•Lock ordering (always lock in a consistent global order) prevents deadlocks
•fcntl F_SETLKW detects deadlocks and returns EDEADLK
•Try-lock + backoff is an alternative to strict ordering
•Coarse-grained locking is simpler but reduces concurrency

Gotchas

•Kernel deadlock detection only works for fcntl locks within one system
•Deadlocks involving semaphores, mutexes, or network resources are not detected by kernel
•Lock ordering requires global knowledge of all lockable resources
•Starvation (indefinite waiting) is different from deadlock but equally problematic

Deadlock: circular wait for resources. Prevent with lock ordering (always acquire in same order), try-lock with backoff, or timeouts. fcntl detects deadlocks (EDEADLK). Four conditions: mutual exclusion, hold-and-wait, no preemption, circular wait.

•Lock ordering prevents deadlocks
•fcntl detects deadlocks (EDEADLK)

/* Deadlock-free: always lock lower offset first */
void lock_ordered(int fd, off_t a, off_t b, off_t size) {
    off_t first = (a < b) ? a : b;
    off_t second = (a < b) ? b : a;
    struct flock fl = {.l_type=F_WRLCK, .l_whence=SEEK_SET};
    fl.l_start = first * size; fl.l_len = size;
    fcntl(fd, F_SETLKW, &fl);
    fl.l_start = second * size;
    fcntl(fd, F_SETLKW, &fl);
}

Kernel deadlock detection only works for fcntl locks

Question 15 / 15

How do POSIX message queues work (mq_open, mq_send, mq_receive)?

POSIX message queues provide a cleaner, fd-based alternative to System V message queues.

Key functions:

#include <mqueue.h>
mqd_t mq_open(const char *name, int oflag, mode_t mode, struct mq_attr *attr);
int mq_send(mqd_t mqdes, const char *msg_ptr, size_t msg_len, unsigned int msg_prio);
ssize_t mq_receive(mqd_t mqdes, char *msg_ptr, size_t msg_len, unsigned int *msg_prio);
int mq_close(mqd_t mqdes);
int mq_unlink(const char *name);
int mq_notify(mqd_t mqdes, const struct sigevent *sevp);

Advantages over System V message queues:

fd-based descriptor (can use with select/poll on some systems)
mq_notify() for asynchronous notification (signal or thread)
Priority-based ordering (highest priority dequeued first)
Cleaner open/close/unlink semantics (like files)
mq_attr lets you set max messages and max message size

Queue name: Must start with / and contain no other slashes.

mq_attr fields:

mq_maxmsg -- maximum number of messages in queue
mq_msgsize -- maximum size of each message
mq_curmsgs -- current number of messages (read-only)
mq_flags -- flags (O_NONBLOCK)

Pseudo Code

1. mqd = mq_open("/myqueue", O_CREAT | O_RDWR, 0666, &attr)
2. Sender: mq_send(mqd, msg, len, priority)
3. Receiver: mq_receive(mqd, buf, max_size, &priority)
   - Receives highest priority message first
   - Blocks if queue is empty (unless O_NONBLOCK)
4. mq_close(mqd)
5. mq_unlink("/myqueue")  -- remove queue name

Async notification:
  mq_notify(mqd, &sigev)  -- signal or thread on message arrival

Code

#include <mqueue.h>
#include <stdio.h>
#include <string.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/wait.h>

#define QUEUE_NAME "/demo_mq"
#define MAX_MSG_SIZE 256
#define MAX_MSGS 10

int main(void) {
    /* Set queue attributes */
    struct mq_attr attr;
    attr.mq_flags = 0;
    attr.mq_maxmsg = MAX_MSGS;
    attr.mq_msgsize = MAX_MSG_SIZE;
    attr.mq_curmsgs = 0;

    /* Create queue */
    mq_unlink(QUEUE_NAME);  /* remove stale queue */
    mqd_t mq = mq_open(QUEUE_NAME, O_CREAT | O_RDWR, 0666, &attr);
    if (mq == (mqd_t)-1) { perror("mq_open"); return 1; }

    pid_t pid = fork();
    if (pid == 0) {
        /* Child: sender */
        mqd_t cmq = mq_open(QUEUE_NAME, O_WRONLY);
        mq_send(cmq, "Low priority", 13, 1);   /* priority 1 */
        mq_send(cmq, "High priority", 14, 10);  /* priority 10 */
        mq_send(cmq, "Medium priority", 16, 5); /* priority 5 */
        mq_close(cmq);
        _exit(0);
    }

    wait(NULL);

    /* Parent: receiver (highest priority first) */
    char buf[MAX_MSG_SIZE + 1];
    unsigned int prio;
    for (int i = 0; i < 3; i++) {
        ssize_t n = mq_receive(mq, buf, MAX_MSG_SIZE, &prio);
        if (n >= 0) {
            buf[n] = '\0';
            printf("Received (prio=%u): %s\n", prio, buf);
        }
    }
    /* Output order: High(10), Medium(5), Low(1) */

    mq_close(mq);
    mq_unlink(QUEUE_NAME);
    return 0;
}

Received (prio=10): High priority
Received (prio=5): Medium priority
Received (prio=1): Low priority

Key Points

•POSIX message queues use fd-like descriptors (mqd_t)
•Messages have priority; highest priority dequeued first
•mq_notify provides async notification (signal or thread callback)
•Queue name must start with / and have no other slashes
•Compile with -lrt on some systems

Gotchas

•mq_receive buffer must be >= mq_msgsize or EMSGSIZE is returned
•Queue persists after process exit until mq_unlink (like shared memory)
•On Linux, POSIX mqueues are mounted at /dev/mqueue (can ls them)
•/proc/sys/fs/mqueue/* limits the number and size of queues

POSIX message queues: mq_open(name), mq_send(mq, msg, len, priority), mq_receive(mq, buf, size, &prio). Priority-ordered, fd-based, supports async notification. Name starts with /. Compile with -lrt.

•Priority-ordered message delivery
•mq_notify for async notification

#include <mqueue.h>
#include <string.h>

int main(void) {
    struct mq_attr a = { .mq_maxmsg = 10, .mq_msgsize = 256 };
    mqd_t mq = mq_open("/test", O_CREAT | O_RDWR, 0666, &a);
    mq_send(mq, "hello", 5, 1);
    char buf[256]; unsigned prio;
    mq_receive(mq, buf, 256, &prio);
    mq_close(mq);
    mq_unlink("/test");
    return 0;
}

Buffer must be >= mq_msgsize or receive fails

Built by onllm.dev

Home GitHub Support awesomePrep