From 8bee08a26f41b39ce14cae9cdab486d3265349f7 Mon Sep 17 00:00:00 2001 From: rpj Date: Sun, 16 Dec 2007 03:47:01 +0000 Subject: Added new Q11 --- FAQ | 50 +++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 49 insertions(+), 1 deletion(-) diff --git a/FAQ b/FAQ index 4f2d449..cb1786c 100644 --- a/FAQ +++ b/FAQ @@ -30,6 +30,9 @@ Q 9 Cancelation doesn't work for me, why? Q 10 How do I generate pthreadGCE.dll and libpthreadw32.a for use with Mingw32? +Q 11 Why isn't pthread_t defined as a scalar (e.g. pointer or int) + like it is for other POSIX threads implementations? + ============================================================================= Q 1 What is it? @@ -400,4 +403,49 @@ This should not be a problem with recent versions of MinGW32. For early versions, see Thomas Pfaff's email at: http://sources.redhat.com/ml/pthreads-win32/2002/msg00000.html ------------------------------------------------------------------------------ - + +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. + -- cgit v1.2.3