8

In a Linux system with multiple processes system V semaphores allow an option of SEM_UNDO preventing a semaphore from getting "stuck" if a process holding the semaphore crashes. What is the correct method to prevent POSIX semaphores getting jammed as a result of a crash in a process holding the semaphore? Or does POSIX guarantee that the semaphore is freed in the case of a crash?

Joe
  • 7,378
  • 4
  • 37
  • 54
  • 1
    Is this answered by http://stackoverflow.com/questions/2053679/how-do-i-recover-a-semaphore-when-the-process-that-decremented-it-to-zero-crashe – Airsource Ltd Jan 27 '15 at 09:04
  • 1
    Yes and no. I was hoping for some authoritative source on POSIX semaphores leaving things in an indeterminate state as a result of a crash. That link certainly offers a way to handle such a situation but without explaining the why / how of what seems to be an oversight from the POSIX spec. I just used SYS V semaphores in the end, but I'm curious to know why POSIX doesn't mandate what seems like the only sensible behaviour of a mutex in a crash. – Joe Jan 27 '15 at 09:08
  • 1
    Well: http://charette.no-ip.com:81/programming/2010-01-13_PosixSemaphores/ - also using the file locking solution. – Airsource Ltd Jan 27 '15 at 09:32
  • The topic is debated in answers to the following question: http://stackoverflow.com/questions/368322/differences-between-system-v-and-posix-semaphores – Iwillnotexist Idonotexist Jan 27 '15 at 22:09

1 Answers1

-1

You can use signal handler for SIGSEGV and then do unlock and remove the signal handler.

// set handler
signal(SIGSEGV, handler);

void handler(int signum) {
// unlock the locked semaphores
signal(SIGSEGV, SIG_DFL);
}
Pointer
  • 627
  • 2
  • 8
  • 19
  • But there's no guarantee which thread catches a SEGV. So there's no guarantee you'll be in the thread that owns the lock. – Joe Feb 02 '15 at 11:17
  • I guess semaphores have no notion of ownership, mutexes do. – Pointer Feb 02 '15 at 12:17