> It keeps track of PID of the last process that acquired it, and if another process can’t acquire it, it can check if the PID is still alive using stat, if it’s dead it will unlock the mutex and reset the field of previous owner.
That's not safe. PIDs are recycled.
The only correct solution I can think of is to place the lock in shared memory, use the futex(2) API, and use set_robust_list (https://linux.die.net/man/2/set_robust_list) to ensure the kernel will unlock a futex if a process dies.
You may (should?) be able to initialize a pthread-based PTHREAD_PROCESS_SHARED + PTHREAD_MUTEX_ROBUST mutex in a shared memory region and have everything just work.
Yup, didn't think of that possibility, thanks for pointing it out.
> You may (should?) be able to initialize a pthread-based PTHREAD_PROCESS_SHARED + PTHREAD_MUTEX_ROBUST mutex in a shared memory region and have everything just work.
Trying this now, I'll make another post if I can get it working. Thanks for the suggestion.
How do others do publish-subscribe architecture on Linux? There's no multicast IPC primitives, and nothing like the Mac's lovely notify(3).
One disgusting technique is to use a file descriptor's "ready" state as a signal. Wait until the fd is readable, then check the shared memory for new data. Surely there's better.
That's not safe. PIDs are recycled.
The only correct solution I can think of is to place the lock in shared memory, use the futex(2) API, and use set_robust_list (https://linux.die.net/man/2/set_robust_list) to ensure the kernel will unlock a futex if a process dies.
You may (should?) be able to initialize a pthread-based PTHREAD_PROCESS_SHARED + PTHREAD_MUTEX_ROBUST mutex in a shared memory region and have everything just work.