Re: Compilation issue with pthreads-win32

["John E. Bossom" <drifting@pioneerwireless.ca>]

HPUX's DCE Threads (which was an implementation of the draft
version of the standard) used a struct. I'll check out Hpux 11.x when  
I get into work to see is the final version followed suit.

Regardless, the standard specifically allows
the flexibility to implement the library either way.
That is why it is pass-by-ref on the API and the
reason for methods such as pthread_equal

John E. Bossom


Quoting Ross Johnson <Ross.Johnson@homemail.com.au>:

> Hi Claude,
>
> Glad you found the library useful and thankyou for the feedback.
>
> You are right that all Unixes (that I know of) define pthread_t as a
> scalar type and that pthread_win32 deviates from this convention by
> using a struct. The projects FAQ offers a history and explanation in
> Question 11, which I've quoted at the end.
>
> IIRC Solaris does not use a pointer but uses an int type that sequences
> to provide a unique id for each new thread in a process. I have no idea
> how Solaris maps this counting value to thread storage when needed nor
> how it does it efficiently when the set of living threads becomes
> sparse, but they do it. Linux and BSD use pointers which are not unique
> if the thread exits and its memory has been allocated to a new
> pthread_t, or any other type for that matter. I know from comments in
> their code that the BSD developers have thought about this issue and
> the possibility of changing away from a pointer type at some point.
>
> Having done so ourselves we no longer get questions about the many
> complex problems that arise when using pointers. We have had a few
> questions like yours to do with porting, all three of which have been
> fairly easily solved AFAIK. I take the blame for the decision but I
> thought it was better to provide application reliability,
> predictability etc. for everyone and accept the occasional but fixable
> compiler breakage.
>
> But the crux of it is this: the POSIX (and now the SUSv3) standard
> allows pthread_t to be scalar or non-scalar and in making it non-scalar
> in pthreads-win we are not just taking advantage of a loophole in the
> standard; the standard has deliberately not defined pthread_t so that
> implementations can define it how they see fit. The notes within the
> standard actually suggest defining pthread_t as a struct exactly as it
> is defined here, to allow inclusion of a 'sequence' counter to render
> the handle unique over time.
>
> But back to your code:
> What would happen if you did not set SSD->id = 0, i.e. just leave it
> unitialised? I'm curious because your code appears not to attempt a
> comparison of the value with 0, e.g. "if (SSD->id == 0) ..." otherwise
> you would see a compiler error attempting to compare a struct.
>
> If you can't avoid initialising a pthread_t variable, I would suggest
> doing it by declaring a special pthread_t constant with the value you
> want (0 in this case), e.g.:
>
> typedef union {
>     pthread_t t;
>     int filler[sizeof(pthread_t)/sizeof(int)];
> } init_t;
>
> const init_t u_init = {.filler = {0}}; # Relies on having a C99
> compliant compiler
>
> Then you can do this to initialise:
>
> SSD->id = u_init.t;
>
> Note that the initialisation of the array u_init.filler only sets the
> first element to 0 explicitly and the remaining elements, if any, are
> set to 0 by default. Since you don't really know how many elements
> there are you should probably avoid trying to initialise more than one
> element, i.e. don't do " = {.filler = {0 , 0}};".
>
> This method means you don't need to break the opacity of the pthread_t
> and it should also be portable.
>
> Also for portability, you should only ever use the pthread_equal()
> function to compare pthread_t types, e.g.:
>
> if (pthread_equal(SSD->id, u_init.t) {
>     ...
> }
>
> And one more thing that I can mention. In pthreads-win32 you can call
> pthread_kill(threadID, 0) to check if threadID is valid, i.e. refers to
> a living thread. It will return ESRCH if invalid. However this is not
> portable and therefore not safe but can sometimes be better than
> nothing. It probably also works for Solaris and works here because we
> can guarantee that threadID is a unique value within the process scope
> and we can determine all of the previous values of living and dead
> threadIDs. (This is not absolutely strictly true of course but is true
> within the practical lifetimes of processes.)
>
> FAQ
> ===
> 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.
>
>
> On 5/02/2011 1:35 AM, Claude LALYRE wrote:
>> Hi Ross,
>>
>> I would like to thank a lot your pthreads-win32 team for the great
> work they achieved.
>> This week, I was in a situation of migrating UNIX source code to
> Windows environment.
>> And helpfully with your project phreads-win32 that task was easily possible.
>>
>> But I encountered some compilation issues. And I have had to declare
> some missing
>> typedef and macros in my code, picked from cygwin header files. And
> surprisingly
>> it was enough for my code being able to compile.
>>
>> So as it was just a small issue, I thought I should give you my point
> of view and
>> the little declarations I made. I think that it should be easily
> integrated in your
>> source code. Just have a look at the posix.h attached file.
>>
>> Another point is concerning the declaration of your type "pthread_t".
> In all UNIX
>> platforms this is formerly a pointer, but in your Windows
> implementation this
>> is a struct object. The issue is that I was given a source file
> containing a SSD
>> object containing a field "id" of type pthread_t.
>>
>> struct SSD {
>>    pthread_t id;
>>    int dummy;
>> }
>>
>> And somewhere else in the code they gave me, I have this
>> SSD->id = 0;
>>
>> And that line of code was not accepted by cl.exe (Windows) compiler !
>> So I face the situation by adding this ugly fix
>>
>> #ifdef WIN32
>> SSD->id.p = 0
>> #else /* WIN32 */
>> SSD->id = 0;
>> #endif /* WIN32 */
>>
>> So I am sorry to tell you this about the most basic type of your
> pthreads-win32 library,
>> but it would have been great to keep the pthread_t type as a pointer
> rather than a struct
>> object. However, as I managed to fix this situation its a tiny issue, an
>> enhancement suggestion rather than a bug...
>>
>> Thank a lot for all youy great job !
>>
>> Claude.
>>
>>
>>
>>