QNX RTOS v4 Knowledge Base
QNX RTOS v4 Knowledge Base
| Title |
Semaphore cleanup for a dying process |
| Ref. No. |
QNX.000006309 |
| Category(ies) |
Development |
| Issue |
Does QNX provide a named semaphore (global) which is managed by the Process manager? I have a shared memory implementation, but if the task with the semaphore dies (SIGSEGV or whatever), the system is hung.
|
| Solution |
If a task dies, and it is sharing a semaphore, you need to handle this in code. Try attaching a signal handler for all the cases
and post the semaphore if the process owns it. There is still some chance for a race condition, but this greatly closes the window.
Plus, named semaphores might not help with this. There is still the same problem -- all that is changed is how one accesses or gains the use of the semaphore, not the behaviour on process exit.
If you put the semaphore in a named shared memory area, then a new process can come along and access the existing semaphore, to post it, if that is the correct behaviour.
Neutrino has named and unnamed semaphores -- but this does not change the behaviour on process exit/termination, there is no automatic posting of the semaphore.
In both QNX4 & Neutrino the semaphores are handled by the kernel. But in no case is it appropriate for the OS to post a semaphore
for a dieing/dead process. This is not how semaphores are defined.
It is quite a valid implementation/use of semaphores to have one process that only ever calls sem_post() and one or more that only ever calls sem_wait(). (This mechanism can be used for dispatching agents.)
Basically, if you need cleanup with semaphores you must handle it yourself, either by trapping the exit conditions and posting in
that case, or by restarting the process, determining the state of the semaphore and posting it if neccessary. Of course, other cleanup will probably be needed as well -- the process that died while it "owned" the semaphore (though that concept doesn't truly exist for semaphores the way it would for mutexes) could have left whatever shared resource is being controlled in an inconsistent state. That must be dealt with as well. |
|
