'\" et
.TH PTHREAD_ATTR_DESTROY "3P" 2013 "IEEE/The Open Group" "POSIX Programmer's Manual"
.SH PROLOG
This manual page is part of the POSIX Programmer's Manual.
The Linux implementation of this interface may differ (consult
the corresponding Linux manual page for details of Linux behavior),
or the interface may not be implemented on Linux.

.SH NAME
pthread_attr_destroy,
pthread_attr_init
\(em destroy and initialize the thread attributes object
.SH SYNOPSIS
.LP
.nf
#include <pthread.h>
.P
int pthread_attr_destroy(pthread_attr_t *\fIattr\fP);
int pthread_attr_init(pthread_attr_t *\fIattr\fP);
.fi
.SH DESCRIPTION
The
\fIpthread_attr_destroy\fR()
function shall destroy a thread attributes object. An implementation
may cause
\fIpthread_attr_destroy\fR()
to set
.IR attr
to an implementation-defined invalid value. A destroyed
.IR attr
attributes object can be reinitialized using
\fIpthread_attr_init\fR();
the results of otherwise referencing the object after it
has been destroyed are undefined.
.P
The
\fIpthread_attr_init\fR()
function shall initialize a thread attributes object
.IR attr
with the default value for all of the individual attributes used by a
given implementation.
.P
The resulting attributes object (possibly modified by setting
individual attribute values) when used by
\fIpthread_create\fR()
defines the attributes of the thread created. A single attributes
object can be used in multiple simultaneous calls to
\fIpthread_create\fR().
Results are undefined if
\fIpthread_attr_init\fR()
is called specifying an already initialized
.IR attr
attributes object.
.P
The behavior is undefined if the value specified by the
.IR attr
argument to
\fIpthread_attr_destroy\fR()
does not refer to an initialized thread attributes object.
.SH "RETURN VALUE"
Upon successful completion,
\fIpthread_attr_destroy\fR()
and
\fIpthread_attr_init\fR()
shall return a value of 0; otherwise, an error number shall be returned
to indicate the error.
.SH ERRORS
The
\fIpthread_attr_init\fR()
function shall fail if:
.TP
.BR ENOMEM
Insufficient memory exists to initialize the thread attributes object.
.P
These functions shall not return an error code of
.BR [EINTR] .
.LP
.IR "The following sections are informative."
.SH EXAMPLES
None.
.SH "APPLICATION USAGE"
None.
.SH RATIONALE
Attributes objects are provided for threads, mutexes, and condition
variables as a mechanism to support probable future standardization in
these areas without requiring that the function itself be changed.
.P
Attributes objects provide clean isolation of the configurable aspects
of threads. For example, ``stack size''
is an important attribute of a thread, but it cannot be expressed
portably. When porting a threaded program, stack sizes often need to
be adjusted. The use of attributes objects can help by allowing the
changes to be isolated in a single place, rather than being spread
across every instance of thread creation.
.P
Attributes objects can be used to set up ``classes' of threads with
similar attributes; for example, ``threads with large stacks and high
priority'' or ``threads with minimal stacks''. These classes can be
defined in a single place and then referenced wherever threads need to
be created. Changes to ``class'' decisions become straightforward, and
detailed analysis of each
\fIpthread_create\fR()
call is not required.
.P
The attributes objects are defined as opaque types as an aid to
extensibility. If these objects had been specified as structures,
adding new attributes would force recompilation of all multi-threaded
programs when the attributes objects are extended; this might not be
possible if different program components were supplied by different
vendors.
.P
Additionally, opaque attributes objects present opportunities for
improving performance. Argument validity can be checked once when
attributes are set, rather than each time a thread is created.
Implementations often need to cache kernel objects that are expensive
to create. Opaque attributes objects provide an efficient mechanism to
detect when cached objects become invalid due to attribute changes.
.P
Since assignment is not necessarily defined on a given opaque type,
implementation-defined default values cannot be defined in a portable
way. The solution to this problem is to allow attributes objects to be
initialized dynamically by attributes object initialization functions,
so that default values can be supplied automatically by the
implementation.
.P
The following proposal was provided as a suggested alternative to the
supplied attributes:
.IP " 1." 4
Maintain the style of passing a parameter formed by the
bitwise-inclusive OR of flags to the initialization routines (\c
\fIpthread_create\fR(),
\fIpthread_mutex_init\fR(),
\fIpthread_cond_init\fR()).
The parameter containing the flags should be an opaque type for
extensibility. If no flags are set in the parameter, then the objects
are created with default characteristics. An implementation may
specify implementation-defined flag values and associated behavior.
.IP " 2." 4
If further specialization of mutexes and condition variables is
necessary, implementations may specify additional procedures that
operate on the
.BR pthread_mutex_t
and
.BR pthread_cond_t
objects (instead of on attributes objects).
.P
The difficulties with this solution are:
.IP " 1." 4
A bitmask is not opaque if bits have to be set into bitvector
attributes objects using explicitly-coded bitwise-inclusive OR
operations. If the set of options exceeds an
.BR int ,
application programmers need to know the location of each bit. If bits
are set or read by encapsulation (that is, get and set functions), then
the bitmask is merely an implementation of attributes objects as
currently defined and should not be exposed to the programmer.
.IP " 2." 4
Many attributes are not Boolean or very small integral values. For
example, scheduling policy may be placed in 3-bit or 4-bit, but
priority requires 5-bit or more, thereby taking up at least 8 bits out
of a possible 16 bits on machines with 16-bit integers. Because of
this, the bitmask can only reasonably control whether particular
attributes are set or not, and it cannot serve as the repository of the
value itself. The value needs to be specified as a function parameter
(which is non-extensible), or by setting a structure field (which is
non-opaque), or by get and set functions (making the bitmask a
redundant addition to the attributes objects).
.P
Stack size is defined as an optional attribute because the very notion
of a stack is inherently machine-dependent. Some implementations may
not be able to change the size of the stack, for example, and others
may not need to because stack pages may be discontiguous and can be
allocated and released on demand.
.P
The attribute mechanism has been designed in large measure for
extensibility. Future extensions to the attribute mechanism or to any
attributes object defined in this volume of POSIX.1\(hy2008 has to be done with care so
as not to affect binary-compatibility.
.P
Attributes objects, even if allocated by means of dynamic allocation
functions such as
\fImalloc\fR(),
may have their size fixed at compile time. This means, for example, a
\fIpthread_create\fR()
in an implementation with extensions to
.BR pthread_attr_t
cannot look beyond the area that the binary application assumes is
valid. This suggests that implementations should maintain a size field
in the attributes object, as well as possibly version information, if
extensions in different directions (possibly by different vendors) are
to be accommodated.
.P
If an implementation detects that the value specified by the
.IR attr
argument to
\fIpthread_attr_destroy\fR()
does not refer to an initialized thread attributes object, it is
recommended that the function should fail and report an
.BR [EINVAL] 
error.
.P
If an implementation detects that the value specified by the
.IR attr
argument to
\fIpthread_attr_init\fR()
refers to an already initialized thread attributes object, it is
recommended that the function should fail and report an
.BR [EBUSY] 
error.
.SH "FUTURE DIRECTIONS"
None.
.SH "SEE ALSO"
.ad l
.IR "\fIpthread_attr_getstacksize\fR\^(\|)",
.IR "\fIpthread_attr_getdetachstate\fR\^(\|)",
.IR "\fIpthread_create\fR\^(\|)"
.ad b
.P
The Base Definitions volume of POSIX.1\(hy2008,
.IR "\fB<pthread.h>\fP"
.SH COPYRIGHT
Portions of this text are reprinted and reproduced in electronic form
from IEEE Std 1003.1, 2013 Edition, Standard for Information Technology
-- Portable Operating System Interface (POSIX), The Open Group Base
Specifications Issue 7, Copyright (C) 2013 by the Institute of
Electrical and Electronics Engineers, Inc and The Open Group.
(This is POSIX.1-2008 with the 2013 Technical Corrigendum 1 applied.) In the
event of any discrepancy between this version and the original IEEE and
The Open Group Standard, the original IEEE and The Open Group Standard
is the referee document. The original Standard can be obtained online at
http://www.unix.org/online.html .

Any typographical or formatting errors that appear
in this page are most likely
to have been introduced during the conversion of the source files to
man page format. To report such errors, see
https://www.kernel.org/doc/man-pages/reporting_bugs.html .