From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26650 invoked by alias); 1 Sep 2003 07:22:08 -0000 Mailing-List: contact pthreads-win32-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sources.redhat.com Received: (qmail 26629 invoked from network); 1 Sep 2003 07:22:06 -0000 Received: from unknown (HELO real.ise.canberra.edu.au) (137.92.140.34) by sources.redhat.com with SMTP; 1 Sep 2003 07:22:06 -0000 Received: from callisto.canberra.edu.au (special.ise.canberra.edu.au [137.92.140.39]) by real.ise.canberra.edu.au (8.11.6/8.11.6) with ESMTP id h817LHi13034; Mon, 1 Sep 2003 17:21:32 +1000 Message-ID: <3F52F356.3080802@callisto.canberra.edu.au> Date: Mon, 01 Sep 2003 07:22:00 -0000 From: Ross Johnson Reply-To: rpj@callisto.canberra.edu.au User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Will Bryant CC: pthreads-win32@sources.redhat.com Subject: Re: How is pthread_self() implemented? References: <1062352346.4373.7.camel@william> <3F52CBD0.2070205@ise.canberra.edu.au> <07ea01c37043$43e02a70$2b01a8c0@moose> In-Reply-To: <07ea01c37043$43e02a70$2b01a8c0@moose> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00085.txt.bz2 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. // 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