This is the mail archive of the mailing list for the pthreas-win32 project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: How is pthread_self() implemented?

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.


// 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)
posixGuest[guest] = pthread_self(); // Only needed sometimes e.g. see thread D
// Mingle
while ( ! (champaigneChilled && cakeIced ) ) {
pthread_cond_wait(&CV, &CVLock);


// Thread B (Win32 or POSIX thread):

   // Ice cake thread
   cakeIced = 1;

// Thread C (Win32 or POSIX thread):

   // Chill champaigne thread
   champaigeChilled = 1;

// 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++)

Regards. Ross

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]