Re: How is pthread_self() implemented?

[Ross Johnson <rpj at callisto dot canberra dot edu dot au>]

Ross Johnson wrote:

> Will Bryant wrote:
>
> > > John Bossom's original design also allows for pre-existing Win32 
> > > threads
> > > to use any POSIX routines, and therefore fully interact with POSIX
> > > threads, by creating a one-time-only on-the-fly detached POSIX thread
> > > handle for the Win32 thread.
> > >   
> >
> >
> > So it is safe to use all pthreads-win32 functions from threads not 
> > created
> > using the pthreads interface?  I have an application where nearly all 
> > of the
> > code only needs to use standard windows threads, but there are a 
> > couple of
> > condition variables that I'd like to be able to use...
> Note that non-POSIX threads are regarded by pthreads-win32 as detached 
> and deferred-cancelable initially. However, I don't think there's any 
> reason a non-POSIX thread can't subsequently change it's cancelability 
> type. There's no way it can make itself joinable though. Apart from 
> that, just about everything should work.
>
> In particular, for condition variables I haven't proven the following 
> but I believe it should all work properly. And since this should work, 
> then so should POSIX read-write locks. Note that you odn't need to 
> explicitly call pthread_self() unless you need the POSIX thread 
> handle. Any routine that needs it internally will cause the POSIX 
> handle to be created implicitly.

When I thought about this some more I realised that you won't be able to 
cancel an 'implicit' POSIX thread as I've claimed in the code below. 
Cancelation in pthreads-win32 depends on establishing a setjmp point (or 
a catch clause in the case of the C++/SEH versions of the library). This 
is done inside of the POSIX thread startup code and so there won't be 
one for 'implicit' POSIX threads.

For now therefore, the library should probably be fixed to initialise 
'implicit' POSIX handles with cancelation type PTHREAD_CANCEL_DISABLE, 
and prevent threads from changing this value subsequently.

Otherwise, the rest of it should work.

Regards.
Ross

> // Global
>
> pthread_t    posixGuest[MAX_GUESTS];
> pthread_mutex_t    CVLock = PTHREAD_MUTEX_INITIALIZER;
> pthread_cond_t    CV = PTHREAD_COND_INITIALIZER;
> int champaigneChilled = 0;
> int cakeIced = 0;
> int chaos = 0;
> int mayhem = 0;
> long    guest = 0;
>
> // Thread A (Win32 or POSIX thread):
>
>    // Party guest thread
>    ...
>    if ((guest = InterLockedIncremement(&guest)) >= MAX_GUESTS)
>        return(gateCrasher);
>    posixGuest[guest] = pthread_self();    // Only needed sometimes 
> e.g. see thread D
>    // Mingle
>    pthread_mutex_lock(&CVLock);
>    pthread_cleanup_push(pthread_mutex_unlock(&CVLock));
>    while ( ! (champaigneChilled && cakeIced ) ) {
>        pthread_cond_wait(&CV, &CVLock);
>    }
>    pthread_cleanup_pop(1);
>
>    toastBirthdaySubject();
>    eatCake();
>    ...
>
> // Thread B (Win32 or POSIX thread):
>
>    // Ice cake thread
>    ...
>    cakeIced = 1;
>    pthread_cond_broadcast(&CV);
>    ...
>
> // Thread C (Win32 or POSIX thread):
>
>    // Chill champaigne thread
>    ...
>    champaigeChilled = 1;
>    pthread_cond_broadcast(&CV);
>    ...
>
> // Thread D (Win32 or POSIX thread):
>
>    // Monitor party thread
>    ...
>    if (chaos && meyhem) {
>        // Evict our guests
>        for (i = 0; i < MAX_GUESTS && pthread_kill(posixGuest[i], 0) == 
> 0; i++)
>            pthread_cancel(posixGuest[i]);
>    }
>    ...
>
>
> Regards.
> Ross