After creating a semaphore in a share memory with this function sem_init(
sem_t * sem, int pshared=1, unsigned value )
One of the process call sem_destroy. But the documentation about sem_destroy
say this.
The effect of using a semaphore after it has been destroyed is undefined.
Also, if you destroy a semaphore on which other process’s are currently
blocked, they are unblocked, with
an error (EINVAL).
How the other process can know the semaphore has been destroyed if the where
not block or waiting.
Thanks.
Rejean Senecal <rsenecal@oerlikon.ca-no-spam> wrote:
After creating a semaphore in a share memory with this function sem_init(
sem_t * sem, int pshared=1, unsigned value )
One of the process call sem_destroy. But the documentation about sem_destroy
say this.
The effect of using a semaphore after it has been destroyed is undefined.
Also, if you destroy a semaphore on which other process’s are currently
blocked, they are unblocked, with
an error (EINVAL).
How the other process can know the semaphore has been destroyed if the where
not block or waiting.
My understanding is that they can’t. Essentially, you shouldn’t
destroy a semaphore that is in use, or could potentially be used
again. To do so, or expect to do so, is to write broken code.
It would probably be cleaner to allow the automatic sem_destroy() to
happen when the shared memory region is released, rather than to
explicitly sem_destroy() it. If you shm_unlink() the shared memory
name, the memory will be freed when all open fds and mapping of it
are closed/unmapped (both of which happen automatically on process
death) and when the last reference to the memory is gone, it will
be freed by the OS (returned to the free pool) and all synchronisation
structures in it (semaphores, condvars, mutexes) will be released
(destroyed).
-David
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.