From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2310 invoked by alias); 1 Sep 2003 15:49:03 -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 2292 invoked from network); 1 Sep 2003 15:48:59 -0000 Received: from unknown (HELO real.ise.canberra.edu.au) (137.92.140.34) by sources.redhat.com with SMTP; 1 Sep 2003 15:48:59 -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 h81Flxi01454; Tue, 2 Sep 2003 01:48:10 +1000 Message-ID: <3F536A19.7040500@callisto.canberra.edu.au> Date: Mon, 01 Sep 2003 15:49: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: rpj@callisto.canberra.edu.au CC: Will Bryant , 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> <3F52F356.3080802@callisto.canberra.edu.au> In-Reply-To: <3F52F356.3080802@callisto.canberra.edu.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003/txt/msg00086.txt.bz2 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 >