6

I am trying to use POSIX named semaphore for cross-process synchronization. I noticed that after the process died or exit, the semaphore is still open by the system.

Is there anyway to make it closed/released after the process (which open it) die or exit?

S.X
  • 61
  • 1
  • 2
  • Please show us an example that reproduces your issue. As of now, it's hard to tell what exactly causes this issue. – fuz Jan 13 '16 at 00:39
  • The [sem_overview man page](http://linux.die.net/man/7/sem_overview) says: "POSIX named semaphores have kernel persistence: if not removed by sem_unlink(3), a semaphore will exist until the system is shut down". If that doesn't help then please clarify your question. – kaylum Jan 13 '16 at 00:46
  • i understand that from the POSIX doc, it will not unlink the semaphore by default when the process crash or exit. I just wonder if there is any option or workaround to do that. – S.X Jan 13 '16 at 00:51
  • @S.X "I just wonder if there is any option or workaround to do that." - definitely not in POSIX. Some *nix systems have extensions to support the behavior, some not. All portable "solutions" revolve around: check periodically (e.g. script from cron) if the applications are running, and if not, clean-up the SysV resources. – Dummy00001 Jan 14 '16 at 09:31

2 Answers2

6

An earlier discussion is here: How do I recover a semaphore when the process that decremented it to zero crashes?. They discussed several possible solutions there.

In short:

  • No. POSIX semaphores are not released if the owning process crashes or is killed by signals. The waiting process will have to wait forever. You can't work around this as long as you stick with semaphores.
  • You can use sockets or file locks to implement the inter-process synchronization, which can be released automatically when the process exits. The question owner I posted above eventually chose the file locks. See his answer. In the comment area, he posted a link to his blog that discusses this issue.

Other links that might help:

Community
  • 1
  • 1
yaobin
  • 2,436
  • 5
  • 33
  • 54
4

You seem to be having a conceptual problem with inter-process communication. An IPC mechanism's lifetime cannot be tied directly to the life cycle of any one process because then it could disappear out from under other processes accessing it. It is intentional that named semaphores persist until explicitly removed.

The Linux sem_overview(7) manual page, though not an authoritative specification, gives a run-down of semaphore life cycle management:

The sem_open(3) function creates a new named semaphore or opens an existing named semaphore. After the semaphore has been opened, it can be operated on using sem_post(3) and sem_wait(3). When a process has finished using the semaphore, it can use sem_close(3) to close the semaphore. When all processes have finished using the semaphore, it can be removed from the system using sem_unlink(3).

As the documentation for sem_unlink() makes clear, you can unlink a semaphore while processes still have it open. No processes can thereafter sem_open() that semaphore, and ultimately it will be cleaned up when the number of processes that have it open falls to zero. This is intentionally analogous to regular files.

If indeed there is one process that should be responsible for cleaning up a given named semaphore, then you should be sure that it sem_unlink()s it. Two reasonably good alternatives are to unlink it as soon as you are satisfied that all other processes that need it have opened it, or to register an exit handler that handles the unlinking. If viable, the former is probably better.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
  • thanks for your reply. Is it possible to have a time-bounded semaphore that automatically clean up itself after some time? – S.X Jan 13 '16 at 01:05
  • @S.X, POSIX semaphores do not have such a behavior, built in, and to the extent that such a thing is conceivable, the closest you could come would be one that was *unlinked* after a fixed delay. And there are several ways you can write a *program* to handle that. – John Bollinger Jan 14 '16 at 01:52
  • I like your comment that "An IPC mechanism's lifetime cannot be tied directly to the life cycle of any one process". This makes a lot of sense to me! – yaobin May 17 '17 at 14:23
  • `An IPC mechanism's lifetime cannot be tied directly to the life cycle of any one process`: Maybe not always, but the OS could be more helpful than it is. First, let's just note that `release`, `close`, `unlink` and `cleanup` all have different and specific semantics. It seems to me that it would be very helpful to have the OS automatically `release` a semaphore acquired by a given process if the process exits without having done that explicitly. Similarly, if it was possible to scope a semaphore to only the parent and child processes, the OS could automatically `cleanup`. – Roger Dahl Jun 03 '19 at 18:32
  • @RogerDahl, it *is* possible to scope a POSIX semaphore to only parent and child. One uses an *unnamed* semaphore for that purpose, but the OP has explicitly chosen a named one instead. As for automatic release, sure, that would be useful -- right up until it wasn't. But if you want that, then you have the option of choosing System V semaphores. – John Bollinger Jun 03 '19 at 19:21
  • As for the differences between releasing a semaphore, closing it, and unlinking it, and their relationship to when the semaphore gets cleaned up, these all have useful and sensible semantics. They *shouldn't* do the same thing. Now I don't mean to imply that the POSIX semaphore interface is without any warts or flaws (much less the SysV interface), but it is flexible and highly serviceable, and pretty natural. – John Bollinger Jun 03 '19 at 19:25
  • @JohnBollinger Thanks for the info. I agree that the semantics are sensible. I just thought both the question and answer were a bit unclear on what the desired behavior would be. Odd that POSIX has less functionality than System V re. semaphores. – Roger Dahl Jun 03 '19 at 23:23
  • Do named semaphores survive after a system reboot? – D. Jones Mar 30 '20 at 16:27
  • No, @D.Jones, named semaphores do not have a representation in persistent storage, and therefore do not survive a reboot. You can cause them to be *recreated* them during system startup, but typically, they are instead created at need by the applications that use them. – John Bollinger Mar 30 '20 at 22:15