Consider providing posix mutex?

[madjxatw]

Will this package provide posix mutex? In the cases where mutex fits, putting posix robust shared mutex in shared memory might be preferable for inter-process synchronization over named semaphore because posix semaphore does not release itself when the process holding it terminates unexpectedly, which might block other waiting processes indefinitely.

[osvenskan]

Hi @madjxatw, thanks for the suggestion. I don't have plans to provide the provide any interface to the posix mutex from the threads library. The idea of putting a threading mutex in IPC shared memory is interesting. Is that a technique that's used in some C programs?

[madjxatw]

@osvenskan Yes. We could even put unnamed semaphores in the shared memory for inter-process synchronization. However, the posix semaphore does not has a feature that is equivalent to SEM_UNDO of the sysv counterpart, and we must use other tricks to avoid deadlock. For example, we may use a standalone watchdog program monitoring two involved processes, once the one that should have posted the semaphore terminates unexpectedly, the watchdog can post the semaphore to unblock the other waiting process. Hence, for the inter-process communication between two processes, some people tend to use the pthread mutex with PTHREAD_PROCESS_SHARED and PTHREAD_MUTEX_ROBUST attributes set, and then share them via shared memory. The robust pthread mutex unlocks itself once the process holding it terminates.

[osvenskan]

Thanks for the context. My memories are hazy, but I seem to recall that SEM_UNDO of SysV semaphores has its own problems. But they might be restricted to platform-specific quirks, and if one's code doesn't need to be portable, then it might be fine.

You're aware of my SysV IPC module for Python, yes? (https://github.com/osvenskan/sysv_ipc)

I appreciate the suggestion, and I'll certainly take it under consideration. FYI, I don't have the time right now to tackle a feature of this size, and I don't know when I might get that time. It doesn't look tremendously complicated, but it would increase the size of the module (code, unit tests, documentation, etc.) by about one third, and I'd have to exercise the new code on Mac, Linux, and BSD to look for platform-specific quirks. That's harder for me than it used to be since I can no longer use Virtualbox to run Linux and BSD on my M-series Mac. I'm sorry if this is discouraging, but I'm trying to set realistic expectations both for you and for myself. 🙂