From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24941 invoked by alias); 31 Mar 2009 13:33:33 -0000 Received: (qmail 24924 invoked by uid 22791); 31 Mar 2009 13:33:32 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,J_CHICKENPOX_13,J_CHICKENPOX_41,SPF_PASS X-Spam-Check-By: sourceware.org Received: from flexo.grapevine.net.au (HELO flexo.grapevine.net.au) (203.129.32.140) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 31 Mar 2009 13:33:24 +0000 Received: from localhost (localhost [127.0.0.1]) by flexo.grapevine.net.au (Postfix) with ESMTP id A5868583078; Wed, 1 Apr 2009 00:33:21 +1100 (EST) Received: from flexo.grapevine.net.au ([127.0.0.1]) by localhost (flexo.grapevine.net.au [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9LJZhz-Ai79; Wed, 1 Apr 2009 00:33:21 +1100 (EST) Received: from localhost.localdomain (ppp-182.208.127.121.grapevine.net.au [121.127.208.182]) by flexo.grapevine.net.au (Postfix) with ESMTP id 524D658305E; Wed, 1 Apr 2009 00:33:21 +1100 (EST) Message-ID: <49D21BA0.6010202@homemail.com.au> Date: Tue, 31 Mar 2009 13:33:00 -0000 From: Ross Johnson User-Agent: Thunderbird 2.0.0.14 (X11/20080501) MIME-Version: 1.0 To: Tobias Ljunggren CC: pthreads-win32@sourceware.org Subject: Re: pthread_t and stl maps References: <1238493105.d943181cjtl@myrealbox.com> In-Reply-To: <1238493105.d943181cjtl@myrealbox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact pthreads-win32-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: pthreads-win32-owner@sourceware.org X-SW-Source: 2009/txt/msg00023.txt.bz2 Tobias Ljunggren wrote: > Hello, > > I've been using pthreads-win32 (rel 2.7.0) for some time but recently changed to current head in CVS due to win64 support. > > First of all I must say that the upgrade from 2.7.0 was easier than I thought. A good work to all of you who are involved with the development! > > I use the same code base for both Linux and Windows builds and it works great. > > I use a stl map to store some static data that are shared within the same thread but not by other threads. The change of pthread_t to a struct requires a sort function if the key in a map is a thread identifier (pthread_t). > > What should the correct ordering be? I looked at the code in pthread_equal and guess that "(left.p < right.p)" isn't enough but is (left.p < right.p && left.x < right.x) ok? > Hi Tobias, pthread_t, as with most of the pthread*_t types, is intended to be opaque to applications, so you should not be making any assumptions about it's representation and should not be doing much other than storing it or retrieving it or testing it for equality, e.g. using pthread_equal(). Having said that, you could use a union like this, which makes no assumptions about pthread_t and so should be portable:- typedef union { pthread_t pth; unsigned char b[sizeof(pthread_t)]; } pthcmp_t; int pthcmp(pthread_t left, pthread_t right) { /* * Compare two pthread handles in a way that imposes a repeatable but arbitrary * ordering on them. * I.e. given the same set of pthread_t handles the ordering should be the same * each time but the order has no particular meaning other than that. E.g. * the ordering does not imply the thread start sequence, or any other * relationship between threads. * * Return values are: * 1 : left is greater than right * 0 : left is equal to right * -1 : left is less than right */ int i; pthcmp_t L, R; L.pth = left; R.pth = right; for (i = 0; i < sizeof(pthread_t); i++) { if (L.b[i] > R.b[i]) return 1; else if (L.b[i] < R.b[i]) return -1; } return 0; } > Best regards, > Tobias > >