2

I have two programs interacting via a shared memory segment. When using the segment for read or write, they hold a lock.

Should either of them crash (get killed, typically - possibly with something untrappable) in a critical section, I would like them to release the lock so that the shmem isn't locked out completely.

Other questions point the way to the answer in Windows, Java, etc. but how do you do it in Unix (and specifically Linux)?

(I'm not attached to the pthreads mutex functions; SysV semaphores or anything else will do just fine.)

ijw
  • 4,376
  • 3
  • 25
  • 29
  • possible duplicate of [Mutex in shared memory when one user crashes?](http://stackoverflow.com/questions/1700299/mutex-in-shared-memory-when-one-user-crashes) – Maerlyn Aug 17 '12 at 21:18

3 Answers3

8

I believe POSIX robust mutexes are what you're looking for:

http://www.opengroup.org/onlinepubs/9699919799/functions/pthread_mutexattr_getrobust.html

R.. GitHub STOP HELPING ICE
  • 208,859
  • 35
  • 376
  • 711
2

I think this is by design. If one of the processes crashed, it's likely that the critical section being locked for got interrupted and the data stored in that shared memory segment is inconsistent, invalid, or unsafe. Accessing the memory and operating as though nothing happened from the other process could very well make it crash or worse, depending on what it does.

cdhowie
  • 158,093
  • 24
  • 286
  • 300
  • 2
    Indeed, but POSIX in all its over-engineered wisdom has a solution to this problem, robust mutexes. The thread which attempts to acquire the lock from the crashed process gets notified of the inconsistent state left behind so it can try to repair it or mark it permanently unrecoverable. – R.. GitHub STOP HELPING ICE Nov 10 '10 at 21:50
0

System V semaphores support the SEM_UNDO option to do exactly this. However, unlike robust mutexes this will not notify the next thread to acquire the lock. On the upside, they are more portable than robust mutexes.

jilles
  • 10,509
  • 2
  • 26
  • 39
  • System V semaphores are a lot heavier and slower than mutexes, requiring kernel-space interaction for all operations. I would stay away from them unless you need to support platforms without robust mutex support. If you're on Linux, also see the bugs section of the manpage for `semop` regarding `SEM_UNDO`. – R.. GitHub STOP HELPING ICE Nov 10 '10 at 23:08
  • glibc's robust mutexes are so fast because glibc takes dangerous shortcuts. There is no guarantee that the mutex still exists when the kernel marks it as "will cause EOWNERDEAD". If the mutex was destroyed and the memory replaced by a memory mapped file that happens to contain the last owning thread's ID at the right place and the last owning thread terminates just after writing the lock word (but before fully removing the mutex from its list of owned mutexes), the file is corrupted. Solaris and will-be-FreeBSD9 robust mutexes are slower because they do not want to take this risk. – jilles Nov 21 '10 at 23:05
  • 1
    I don't follow your claim that the implementation is unsafe. Could you provide a citation? You cannot destroy a mutex that's locked, so I don't see how the situation you described could occur. – R.. GitHub STOP HELPING ICE Aug 14 '12 at 03:24
  • You cannot destroy a mutex that is locked, but you can destroy a mutex and then place something at that address that happens to look like a locked mutex. The kernel will not know the difference. Description by a FreeBSD pthread developer: http://lists.freebsd.org/pipermail/svn-src-user/2010-November/003668.html – jilles Aug 17 '12 at 22:14
  • I was sufficiently interested in this topic that I opened a new question on it: http://stackoverflow.com/questions/11945429/race-condition-in-glibc-nptl-linux-robust-mutexes; I agree that there's a race similar to the one you described in the email you just linked to. Thankfully, it can be avoided by considering the VM mappings a shared resource that must be locked for the duration of the atomic mutex unlock and removal from the robust-list pending slot. – R.. GitHub STOP HELPING ICE Aug 17 '12 at 22:25