Installation guide

• pthread_attr_setname_np(3)
• pthread_cond_getname_np(3)
• pthread_cond_setname_np(3)
• pthread_getname_np(3)
• pthread_key_getname_np(3)
• pthread_key_setname_np(3)
• pthread_mutex_getname_np(3)
• pthread_mutex_setname_np(3)
• pthread_rwlock_getname_np(3)
• pthread_rwlock_setname_np(3)
• pthread_setname_np(3)
For more information about object naming, see the reference pages for these
routines.
5.3.7 DECthreads Metering Capability May Not Be Reliable in
Some Situations
In this release, the metering capabilities of DECthreads may not be reliable in
a process that forks.
5.3.8 Memory Alignment Issue
Although older Alpha processors (prior to the 21264 chip) can only access
memory in units of at least a quadword (8 bytes), multiple variables, each of
which is less than eight bytes, can occupy the same quadword in memory. In
such cases, multithreaded programs might experience a problem if two or
more threads read the same quadword, update different parts of it, then
independently write their respective copies back to memory. The last thread
to write the quadword overwrites any data previously written to other parts of
the quadword. This can happen even though each thread protects its part of
the quadword with its own mutex.
The Tru64 UNIX C compiler protects scalar variables against this problem
by aligning them in memory on quadword (8-byte) boundaries. However, in
composite data objects such as structures or arrays, the compiler aligns
members on their natural boundaries. For example, a 2-byte member is
aligned on a 2-byte boundary. Because of this, any adjacent members of the
composite object that total eight bytes or less could occupy the same
quadword in memory.
Inspect your multithreaded application code to determine if you have a
composite data object in which adjacent members could share the same
5–6 Development Environment Notes