Locking mechanisms for shared-memory consistency

Question

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.

Answer 1

So, doing some research I've found that System V semaphores have a flag called SEM_UNDO wich can revert the lock state when the program fails, but that's not guaranteed to work.

SEM_UNDO would unlock the semaphore if process crashes. If processes crashed due to corruption of the shared memory, there is nothing semaphores can do for you. OS can't undo the state of shared memory.

If you need to be able to roll-back state of the shared memory, then you have to implement something on your own. I have seen at least two models which deal with that.

First model before modifying anything in shared memory was taking a snapshot of the structure, saving in a list in the shared memory. If any any other process was able to get the lock and the list wasn't empty, it was undoing whatever the crashed process might have changed.

Second model is to make copies of the shm structures in the local memory and keep the lock locked for the whole transaction. When transaction is being committed, before releasing the lock, simply copy the structures from local memory into the shared memory. Probability that app would crash during copy is lower and intervention by external signals can be blocked by using sigprocmask(). (Locking in the case better be well partitioned over the data. E.g. I have seen tests with set of 1000 locks for 10Mln records in shm accessed by 4 concurrent processes.)