Linux
UNIX
multiprocessing
mutex
concurrency

Is it possible to use mutex in multiprocessing case on Linux/UNIX ?

Master System Design with Codemia

Enhance your system design skills with over 120 practice problems, detailed solutions, and hands-on exercises.

Introduction

Yes, you can use a mutex across processes on Linux and UNIX, but not with the default thread-only setup. A process-shared mutex must live in shared memory and must be initialized with PTHREAD_PROCESS_SHARED, otherwise each process simply locks its own private copy.

That distinction is the whole answer. A normal pthread_mutex_t works inside one process. A multiprocess mutex only works when both the lock and the protected data exist in shared memory visible to all participating processes.

Why a Default Mutex Fails Across Processes

After a fork, the child gets a copied address space. If a mutex is stored in ordinary process memory, the parent and child are not synchronizing on one shared lock in the way most people expect.

To make the lock real across processes, you need:

  1. shared memory created with something like mmap
  2. a mutex stored in that shared region
  3. mutex attributes configured with PTHREAD_PROCESS_SHARED

Leave out any of those pieces and the synchronization is either broken or undefined.

Example with mmap and a Process-Shared Mutex

Here is a minimal example using anonymous shared memory:

c
1#include <pthread.h>
2#include <stdio.h>
3#include <sys/mman.h>
4#include <sys/wait.h>
5#include <unistd.h>
6
7typedef struct {
8    pthread_mutex_t mutex;
9    int counter;
10} shared_state;
11
12int main(void) {
13    shared_state *state = mmap(
14        NULL,
15        sizeof(shared_state),
16        PROT_READ | PROT_WRITE,
17        MAP_SHARED | MAP_ANONYMOUS,
18        -1,
19        0
20    );
21
22    pthread_mutexattr_t attr;
23    pthread_mutexattr_init(&attr);
24    pthread_mutexattr_setpshared(&attr, PTHREAD_PROCESS_SHARED);
25    pthread_mutex_init(&state->mutex, &attr);
26
27    state->counter = 0;
28
29    pid_t pid = fork();
30
31    for (int i = 0; i < 100000; i++) {
32        pthread_mutex_lock(&state->mutex);
33        state->counter++;
34        pthread_mutex_unlock(&state->mutex);
35    }
36
37    if (pid == 0) {
38        munmap(state, sizeof(shared_state));
39        return 0;
40    }
41
42    wait(NULL);
43    printf("counter=%d\n", state->counter);
44
45    pthread_mutex_destroy(&state->mutex);
46    pthread_mutexattr_destroy(&attr);
47    munmap(state, sizeof(shared_state));
48    return 0;
49}

Compile with pthread support:

bash
cc -pthread shared_mutex.c -o shared_mutex
./shared_mutex

The important point is that the counter and the mutex live in the same shared mapping.

Shared Memory Is as Important as the Lock

A process-shared mutex is only useful if the protected state is also shared. Locking around private copies of data gives you the appearance of safety without any real coordination.

This pattern must stay together:

  • shared mutex
  • shared data
  • consistent lock discipline

If one part is not shared, the design is broken.

Consider Other IPC Primitives Too

A process-shared mutex is valid, but it is not automatically the best choice. Depending on the architecture, one of these may fit better:

  • POSIX semaphores for signaling or counting
  • pipes or sockets for message passing
  • message queues for structured work handoff
  • file locks when the shared resource is a file

If your processes do not genuinely need shared mutable memory, message passing is often simpler and less fragile.

Think About Crash Recovery

Processes can die while holding a lock. That is a bigger issue in multiprocess designs than in many toy thread examples. If the shared state matters, think about what should happen when a process exits unexpectedly while owning the mutex.

For more advanced designs, robust mutexes or a higher-level protocol may be necessary. Even if you do not use them, you should at least understand that clean lock release cannot always be assumed.

Common Pitfalls

  • Using a normal pthread_mutex_t in ordinary memory and assuming it coordinates multiple processes.
  • Forgetting PTHREAD_PROCESS_SHARED even though the mutex is in shared memory.
  • Protecting data with a shared mutex when the data itself is not shared.
  • Ignoring process crashes and owner-death scenarios.
  • Choosing shared-memory locking when message passing would have been simpler.

Summary

  • A mutex can work across processes on Linux and UNIX.
  • It must live in shared memory and be initialized as process-shared.
  • The protected data must be shared too, not just the lock.
  • 'mmap plus pthread_mutexattr_setpshared is a common solution.'
  • Consider semaphores or message passing if shared mutable state is not truly necessary.

Course illustration
Course illustration

All Rights Reserved.