POSIX semaphore abandonment problem

[Tristan Schmelcher <tristan dot schmelcher at gmail dot com>]

Hello. I hope I'm sending this to the right place. If not please forgive me. :)

I work with open-source software and glibc/Linux a lot and I'm
wondering if there'd be interest in extending glibc's POSIX named
semaphore support (i.e., sem_open(3)) to solve the semaphore
abandonment problem. Currently, when a process has decremented the
semaphore count and then exits without calling sem_post (as via a
crash or a kill -9), the semaphore is "abandoned" in the locked
state--the count is not auto-incremented. Now admittedly some text in
the spec can be interpreted as _requiring_ that behaviour ("the state
of the semaphore is locked and remains locked until the sem_post()
function is executed and returns successfully",
http://www.opengroup.org/onlinepubs/007908775/xsh/sem_wait.html), but
it makes the API very unattractive for implementing robust
cross-process locks, to the point that the outdated and convoluted
System V semaphores are preferable (though they have their own
problems in the form of a creation/initialization race, c.f.
semget(2)). So it seems to me that some sort of sem_open flag to
provide better semantics would be welcomed.

Suppose something like O_NOABANDON were added. When a named semaphore
is created with this flag, any wait()s that decrement the count are
automatically undone upon process exit/crash or upon sem_close. I
think that would have to be done after-the-fact, at the time of the
next wait() or getvalue() in another process, and it would certainly
require new data to be stored somewhere--perhaps in new files in
/dev/shm. And it would be nice for this functionality to be available
to unnamed semaphores too somehow, though in that case there's nowhere
to supply the new creation flag ... As you can probably tell, I've
thought about this a bit, but not a ton.

Putting the actual implementation aside for now though, would people
generally be open to such an extension?