From owner-freebsd-threads@FreeBSD.ORG Wed Jun 4 07:15:28 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2035E37B401 for ; Wed, 4 Jun 2003 07:15:28 -0700 (PDT) Received: from matou.sibbald.com (matou.sibbald.com [195.202.201.48]) by mx1.FreeBSD.org (Postfix) with ESMTP id A01FA43F93 for ; Wed, 4 Jun 2003 07:15:26 -0700 (PDT) (envelope-from kern@sibbald.com) Received: from [192.168.68.112] (rufus [192.168.68.112]) by matou.sibbald.com (8.11.6/8.11.6) with ESMTP id h54EFEv14730; Wed, 4 Jun 2003 16:15:14 +0200 From: Kern Sibbald To: Mike Makonnen In-Reply-To: <20030604135208.LPAG20810.pop015.verizon.net@kokeb.ambesa.net> References: <1054730325.13630.456.camel@rufus> <20030604135208.LPAG20810.pop015.verizon.net@kokeb.ambesa.net> Content-Type: text/plain Organization: Message-Id: <1054736114.13630.499.camel@rufus> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.2.4 Date: 04 Jun 2003 16:15:14 +0200 Content-Transfer-Encoding: 7bit cc: freebsd-threads@freebsd.org Subject: Re: FreeBSD pthread_equal "bug" X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2003 14:15:28 -0000 Hello, I doubt that this is an accident on Solaris and Linux. They are both excellent implementations (though different) of pthreads, and it is very clear from the values contained that they are not simple memory addresses and are designed to be unique. How they get to their internal structures I don't know and probably it is a few cycles faster than FreeBSD, but it makes pthread_equal() work correctly on their systems. I can say that their numbers are unique over a very large number of threads, and they repeat perfectly for each execution of the program so it isn't likely to be anything left to chance. See my notes below: On Wed, 2003-06-04 at 15:52, Mike Makonnen wrote: > >From the new linux NPTL: > >From the new linux NPTL: > ================= > typedef struct __opaque_pthread *pthread_t; > int > __pthread_equal (thread1, thread2) > pthread_t thread1; > pthread_t thread2; > { > return thread1 == thread2; > } > strong_alias (__pthread_equal, pthread_equal) > > > >From FreeBSD's libc_r implementation: > ========================== > typedef struct pthread *pthread_t; > __weak_reference(_pthread_equal, pthread_equal); > > int > _pthread_equal(pthread_t t1, pthread_t t2) > { > /* Compare the two thread pointers: */ > return (t1 == t2); > } > > In both implementations pthread_t is a pointer to a memory location. > So, your inability to reproduce this on Linux is probably an accident and not an > intentional feature. > > If the two threads (i.e. the dead one and the new one point to the same memory > location using unique id's is not going to solve the problem because both > pointers will be pointing to the same structure (and therefore the same unique > id, even though it will be a different id after the second thread is created). > > The only fool-proof way to do this is to make pthread_t a proper structure > containing a unique id and a pointer to a thread structure, but that would mean > passing a structure on the stack (which is not necessarily bad in itself, > but means someone would have to go through all the threads libraries and > modify appropriately). On Linux, the above is not true. The pthread_id is : typedef unsigned long int pthread_t; > On the other hand I may be mistaken and there may be an easy way to achieve > this :-) Yup, there must be judging by the above. As previously mentioned, I'm not convinced this is something urgent, but I am convinced it is a bug. However, it certainly bit me and took me a bit to figure out. Best regards, Kern