Jump to content
HP.com Home Products and Services Support and Drivers Solutions How to Buy
» Contact HP
HP.com home

Transition Impacts

Tru64 UNIX Software Transition Kit
» 

DSPP Home

» HP STK home
Tru64 UNIX STK
» Home
» Overview
» Tools
» Documentation
» Transition impacts
» Identifier types
» Impact list
» Porting to HP-UX
» FAQ
» Glossary
» Help
» Send us feedback
Site maps
» Tru64 UNIX STK
» DSPP
Content starts here

critical impact:

pthread_cond_signal_int_np, pthread_cond_sig_preempt_int_np - not available (CrUn115)

SIG Impacts TH Impacts

Problem description

The pthread_cond_signal_int_np and pthread_cond_sig_preempt_int_np functions exist on Tru64 UNIX, but not on HP-UX.

The pthread_cond_signal_int_np function allows an application to request that the thread library wake a condition variable waiter from within a signal handling function, something not valid under the POSIX standard. The function does not actually unblock a waiter immediately, but rather causes an undefer request that will be executed later by the library.

The pthread_cond_sig_preempt_int_np function is similar but will attempt to wake a waiter immediately, possibly preempting the caller within the signal handler function. These operations require a critical modification to the condition variable wait logic called "pending wake," where a condition variable wait can be satisfied immediately by an asynchronous wakeup request that occurred earlier; otherwise no reliable protocol is available here because the signal handler function cannot use a mutex. The HP-UX condition variable implementation does not support "pending wake."

Identifiers

C/C++ Functionspthread_cond_sig_preempt_int_np
C/C++ Functionspthread_cond_signal_int_np

See also

Solution description

Review your code and applicable manpages to determine how to resolve this issue.

In some cases, the condition variable signalled from a signal handler function may be replaced by a POSIX semaphore. POSIX semaphores may be posted (sem_post) from a signal handler function to awaken a waiter. In general, it is more effective to avoid asynchronous signal handling in threaded applications. Consider blocking a dedicated thread in sigwait(), sigtimedwait(), or sigwaitinfo() instead of using a signal handler function; or specify the SIGEV_THREAD signal delivery mechanism to cause the signal handler function to run as an independent thread that can lock a mutex and signal a condition variable using standard POSIX functions.

See also


Problem summary

classifications source types OS release severity type
SIG, TH C, C++ any HP-UX 11i version critical unavailable
Printable version
Privacy statement Using this site means you accept its terms Feedback to DSPP
© 2007 Hewlett-Packard Development Company, L.P.