Which synchronisation method to use for data structure that maybe shared by *multiple processes*, [ another semaphore vs mutex question]?

Question

I am currently in the process of developing a user-level device driver for Linux, and I have a data structure that requires concurrent access from multiple processes (assume non related). I'm facing a dilemma regarding the choice of synchronization methods to prevent simultaneous access to the shared resource. I feel that mutex is the correct choice, but ChatGPT suggested that using pthread_mutex is not suitable for my case, and further said that its applicable only for threads of same process, but I can opt for a named semaphore for synchronizing between two process. However, I have reservations about the safety of utilizing a named semaphore, because the concept of ownership is not there for semaphore. So may you please help here?

I tried reading multiple answers regarding when to use semaphore and mutex from below links Difference between binary semaphore and mutex When should we use mutex and when should we use semaphore but the answers in this question didn't address the above question.

Answer 1

regarding the choice of synchronization methods to prevent simultaneous access to the shared resource. I feel that mutex is the correct choice, but ChatGPT suggested that using pthread_mutex is not suitable for my case, and further said that its applicable only for threads of same process, but I can opt for a named semaphore for synchronizing between two process.

ChatGPT is not a reliable source for correct answers to technical questions, but in this case it happens to have lucked onto a bit of a point.

ChatGPT is wrong about pthreads mutexes only being applicable for synchronization inside a single process. Pthreads mutexes default to being process-specific, but you can set them up for inter-process synchronization. To make that work, you need to

• store the mutex in shared memory
• initialize it, once, supplying a pthread_condattr_t object having its pshared attribute enabled

However, having to access the mutex object in shared memory does present a bit of an issue for synchronizing unrelated processes. You could do it with a SysV shared memory segment (and this is a bona fide option) or maybe with a memory-mapped physical file, but it would be pretty difficult with POSIX shared memory. In this sense, a pthreads mutex is more analogous to an unnamed POSIX semaphore than to a named one.

For synchronizing unrelated processes, a semaphore really is the easier option. Either a POSIX named semaphore or a SysV semaphore set would serve. The former has a simpler interface, but the latter has the distinctive feature that a process can be made to back out its semaphore adjustments automatically when it terminates, which is good for cleaning up from abnormal termination.

I have reservations about the safety of utilizing a named semaphore, because the concept of ownership is not there for semaphore.

A semaphore is a more general synchronization construct than a mutex is. Any task you can accomplish via a mutex, you can also accomplish via a semaphore.

As for ownership in particular, you seem to be talking about the fact that the thread or process that locks a mutex is the the only one that may unlock it. So what? If that's what you require then it is a programming error for your program to try to do it any other way. Don't make that error. The mutex helps you out a bit in that area because an erroneous unlock attempt will fail, whereas with a counting semaphore it will succeed. That's not insignificant, but it's a matter of failure mode, not central to how well a semaphore, used correctly, could serve your needs.

BOTTOM LINE: you are overthinking this. Choose an option that is easy to work with for your purposes. Factor the details into their own module, so that if you want to change later then you can do so without much trouble. Either a mutex or a semaphore can serve your purpose, and each choice has both advantages and disadvantages.