This is the mail archive of the
mailing list for the pthreas-win32 project.
New FAQ entry re why pthread_t is a struct
- From: Ross Johnson <Ross dot Johnson at homemail dot com dot au>
- To: Pthreads-Win32 list <pthreads-win32 at sourceware dot org>
- Date: Sun, 16 Dec 2007 15:06:23 +1100
- Subject: New FAQ entry re why pthread_t is a struct
Following the recent thread on this subject I've added a new entry to
the FAQ and committed it to CVS. I've also updated the FAQ web page at
Comments and suggestions welcome.
Q 11 Why isn't pthread_t defined as a scalar (e.g. pointer or int)
like it is for other POSIX threads implementations?
Originally pthread_t was defined as a pointer (to the opaque pthread_t_
struct) and later it was changed to a struct containing the original
pointer plus a sequence counter. This is allowed under both the original
POSIX Threads Standard and the current Single Unix Specification.
When pthread_t is a simple pointer to a struct some very difficult to
debug problems arise from the process of freeing and later allocing
thread structs because new pthread_t handles can acquire the identity of
previously detached threads. The change to a struct was made, along with
some changes to their internal managment, in order to guarantee (for
practical applications) that the pthread_t handle will be unique over the
life of the running process.
Where application code attempts to compare one pthread_t against another
directly, a compiler error will be emitted because structs can't be
compared at that level. This should signal a potentially serious problem
in the code design, which would go undetected if pthread_t was a scalar.
The POSIX Threading API provides a function named pthread_equal() to
compare pthread_t thread handles.
Other pthreads implementations, such as Sun's, use an int as the handle
but do guarantee uniqueness within the process scope. Win32 scalar typed
thread handles also guarantee uniqueness in system scope. It wasn't clear
how well the internal management of these handles would scale as the
number of threads and the fragmentation of the sequence numbering
increased for applications where thousands or millions of threads are
created and detached over time. The current management of threads within
pthreads-win32 using structs for pthread_t, and reusing without ever
freeing them, reduces the management time overheads to a constant, which
could be important given that pthreads-win32 threads are built on top of
Win32 threads and will therefore include that management overhead on top
of their own. The cost is that the memory resources used for thread
handles will remain at the peak level until the process exits.
While it may be inconvenient for developers to be forced away from making
assumptions about the internals of pthread_t, the advantage for the
future development of pthread-win32, as well as those applications that
use it and other pthread implementations, is that the library is free to
change pthread_t internals and management as better methods arise.