Home/ Questions/Q 861339
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T08:57:50+00:00

I’m developing a mechanism for interchanging data between two or more processes using shared

  • 0

I’m developing a mechanism for interchanging data between two or more processes using shared memory on linux. The problem is some level of concurrency control is required to maintain data integrity on the shared memory itself, and as I’m expecting that sometime or another my process could be killed/crash, common lock mechanisms don’t work because they could left the memory in a "locked" state and right after dying, making other processes hung waiting for the lock to be released.

So, doing some research I’ve found that System V semaphores have a flag called SEM_UNDO which can revert the lock state when the program fails, but that’s not guaranteed to work. Another option is to monitor the PID’s from all processes that might use the shared memory and do some control over them if something nasty happens, but I’m not so sure if this might be the right approach to my problem.

Any ideas?

Edit: for explanation purposes, our app need some kind of IPC mechanism with the smallest latency possible. So, I’m open for mechanisms that can handle this requirement also.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I would be curious to know what source you used that said SEM_UNDO was not guaranteed to work. I have not heard that before. I seem to remember reading articles claiming linux’s SYSV IPC in general was buggy but that was quite awhile ago. I am wondering if your info is just an artifact of times past.

    The other thing to consider (if I remember correctly) is that SYSV semaphores have the capability to tell you the PID of the last process to perform a semaphore operation. If you hang you should be able to query to see if the process holding the lock is still alive. Since any process (not just the one holding the lock) can fiddle with semaphore you might exercise control that way.

    Lastly, I’ll put in a pitch for message queues. They might not be appropriate for your speed requirements but they are generally not that much slower than shared memory. In essence they are doing everything you have to do manually with SM anyway but the OS does it all beneath the covers. You get almost as much speed with synchronization, atomicity, ease of use, and a throughly tested mechanism for free.

    • 0