non-critical impact:

msem_init - msemaphores must be in mapped memory (NcWn349)

Problem description

msemaphore structures can be on the heap and the stack on Tru64 UNIX but not on HP-UX.

An msemaphore structure represents a binary semaphore and is initialized with the msem_init function. On both platforms, they are only supported within a mapped file or anonymous memory region created by a successful call to the mmap function, and having both read and write access.

On Tru64 UNIX, however, msemaphore structures can also be on the heap or the stack, although that is not documented or supported. Some applications use this feature because it lets them use the msemaphore interfaces as general synchronization interfaces for both processes and threads.

On HP-UX, the msem_init function will fail if the msemaphore structure is on the heap or the stack. It will return NULL and set errno to EINVAL. The manpage notes that the return value may change to -1 in a future release, but that is incorrect.

Identifiers

msem_init

See also

• Background information on kernel impacts
• msem_init(3)

Solution description

If you are using msemaphore structures on the heap or the stack to synchronize threads, use pthread mutexes instead.

See also

• msem_init(2)
• pthread_mutex_init(3T)

Problem summary