Robust Interprocess Locks

squadrick.github.io

12 points·squadrick··5 comments

> 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.

POSIX shmem is a bit more portable, and flock definitely will do the job. Futex is a linuxism.

> That's not safe. PIDs are recycled.

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.

> How do others do publish-subscribe architecture on Linux?

One great (read: terrible) hack is to do signal delivery on process groups.

I know a multicast AF_UNIX patch for Linux has been floating around for years, but I have no idea if it's ever landed in a mainstream kernel.

My go-to for pseudo-multicast on POSIX/Linux is shared memory + semaphores.

Reply on news.ycombinator.com