linuxpthreadsmutexschedulerpid

If the Linux kernel reassigns a PID, can this cause errors/UB when using C pthread mutexes?


If I'm getting it right, is it possible in the Linux pthread C API to use robust mutexes, that can be shared across processes (by placing them in shared memory), and that allows you to acquire the lock if the proces previously holding it has crashed. However, I wondered if this could lead to problems when assignind PIDs to processes.

For instance, assume I am creating two processes, synchronizing with a mutex:

+-----------+               +-----------+                                 
| Process 1 | +-----------+ | Process 2 |                            
| PID 1000  | |   Mutex   | | PID 1001  |                        
+-----------+ +-----------+ +-----------+                        
      |             |              |             
      |    lock     |              |             
      +------------>|              |             
      |   unlock    |              |             
      |------------>|    lock      |             
      |             |<-------------|             
      |             |   released   |             
      |             |<- - - - - - -X             
      |             |                      +-----------+
      |             |                      | Process 3 |
      |             |                      | PID 1001  |
      |             |                      +-----------+
      |             |           lock             |      
      |             |<---------------------------|
      |             |            ^               |
      |             |            |               |
      |             |          HERE              |                  

then, process 2 crashes, so the mutex should get released, but then a new process 3 spawns up, and it is assigned the same PID of process 2 (extremely unlikely given Linux policy, but technically possible I guess?). In this case, is the mutex correctly freed? If process 3 tries to lock it again, what happens? And if it is process 1 trying to lock?


Solution

  • Your next attempt to lock the mutex, by whichever process or thread that tries it will succeed with EOWNERDEAD (after which that thread should call pthread_mutex_consistent).

    The mechanism that handles this isn't entirely tied to PIDs/TIDs, but rather has the kernel mark the underlying futex (by setting it to FUTEX_OWNER_DIED) when the process/thread exits, execs or dies (where the kernel does check ownership), which the C library later handles.

    If you want more details, I suggest looking at this SO answer