From owner-freebsd-hackers@FreeBSD.ORG Tue Jan 15 21:43:37 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id E4502583 for ; Tue, 15 Jan 2013 21:43:37 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 42BE89ED for ; Tue, 15 Jan 2013 21:43:37 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.6/8.14.6) with ESMTP id r0FLhWHl089341; Tue, 15 Jan 2013 23:43:32 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.4 kib.kiev.ua r0FLhWHl089341 Received: (from kostik@localhost) by tom.home (8.14.6/8.14.6/Submit) id r0FLhWMW089340; Tue, 15 Jan 2013 23:43:32 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 15 Jan 2013 23:43:32 +0200 From: Konstantin Belousov To: Trent Nelson Subject: Re: Getting the current thread ID without a syscall? Message-ID: <20130115214332.GE2522@kib.kiev.ua> References: <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> <20130115213513.GA53047@snakebite.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="FN+gV9K+162wdwwF" Content-Disposition: inline In-Reply-To: <20130115213513.GA53047@snakebite.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: "freebsd-hackers@freebsd.org" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 21:43:38 -0000 --FN+gV9K+162wdwwF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jan 15, 2013 at 04:35:14PM -0500, Trent Nelson wrote: > On Tue, Jan 15, 2013 at 01:16:41PM -0800, Konstantin Belousov wrote: > > On Tue, Jan 15, 2013 at 03:54:03PM -0500, Trent Nelson wrote: > > > Howdy, > > >=20 > > > I have an unusual requirement: I need to get the current thread ID > > > in as few instructions as possible. On Windows, I managed to come > > > up with this glorious hack: > > >=20 > > > #ifdef WITH_INTRINSICS > > > # ifdef MS_WINDOWS > > > # include > > > # if defined(MS_WIN64) > > > # pragma intrinsic(__readgsdword) > > > # define _Py_get_current_process_id() (__readgsdword(0x40)) > > > # define _Py_get_current_thread_id() (__readgsdword(0x48)) > > > # elif defined(MS_WIN32) > > > # pragma intrinsic(__readfsdword) > > > # define _Py_get_current_process_id() (__readfsdword(0x20)) > > > # define _Py_get_current_thread_id() (__readfsdword(0x24)) > > >=20 > > > That exploits the fact that Windows uses the FS/GS registers to > > > store thread/process metadata. Could I use a similar approach on > > > FreeBSD to get the thread ID without the need for syscalls? > > The layout of the per-thread structure used by libthr is private and > > is not guaranteed to be stable even on the stable branches. > >=20 > > Yes, you could obtain the tid this way, but note explicitely that using > > it makes your application not binary compatible with any version of > > the FreeBSD except the one you compiled on. >=20 > Luckily it's for an open source project (Python), so recompilation > isn't a big deal. (I also check the intrinsic result versus the > syscall result during startup to verify the same ID is returned, > falling back to the syscall by default.) For you, may be. For your users, it definitely will be a problem. And worse, the problem will be blamed on the operating system and not to the broken application. >=20 > > You could read the _thread_off_tid integer variable and use the value > > as offset from the %fs base to the long containing the unique thread id. > > But don't use this in anything except the private code. >=20 > Ah, thanks, that's what I was interested in knowing. >=20 > > >=20 > > > (I technically don't need the thread ID, I just need to get some > > > form of unique identifier for the current thread such that I can > > > compare it to a known global value that's been set to the "main > > > thread", in order to determine if I'm currently that thread or n= ot. > > > As long as it's unique for each thread, and static for the lifet= ime > > > of the thread, that's fine.) > > >=20 > > > The "am I the main thread?" comparison is made every ~50-100 opco= des, > > > which is why it needs to have the lowest overhead possible. >=20 > > On newer CPUs in amd64 mode, there is getfsbase instruction which reads > > the %fs register base. System guarantees that %fs base is unique among > > live threads. >=20 > Interesting. I was aware of those instructions, but never assessed > them in detail once I'd figured out the readgsdword approach. I > definitely didn't realize they return unique values per thread > (although it makes sense now that I think about it). >=20 > Thanks Konstantin, very helpful. >=20 > Trent. --FN+gV9K+162wdwwF Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ9c2DAAoJEJDCuSvBvK1BlGQP/3bBYDeADJMGsnGhkOb0R6JC cSzqyFT5U9eizdMfqeedPL49S7J3WhsEVdmrAHUtVgvqx2f/m9BS7F8jnPK6BIbF 1q6wNZLl1BYoLNffFgPuNotNXbZ3S8S3MtdibFsJt9uIeJNWdnvq6EDZZr6bB7O7 Lc4JsEmzPch1NIcC5SH0VRde9FFZcWtks37reOkLtHQKPorMZDmcRQ/8onF3xpMV oliUCsk2SQPdtfoKG9meRstqRnC+Vq8TlEDKtsG4JBFGlhwX1PNrlZKyMaEWIM3E TzuMS/tOKxv4pOO5DE/sZscQJyMYnsQRT4gnYapQs+00JI9IlB3McacMWUl0PbuL 0tQMO1PwuJzJANhJDIaaWJd0nhdg6OdIhnA3PRf6IKC3ApAky8TJo0MbO24AQR2n alfaMHTjC7p4xjhgyy9hE3l/xra6VqGyb5qtVwcLPtkEA3ESMM4Azi98KrU6+Wnu 9lOD4c1Hzy5b9xM0AVmu/Y5Xo8ENHhiLYb0jDBN5soOpsgqnpilUOZB/9a/O9lqA yP2VOG0kbkjaJZCqeUqFWRt5f0bcqxkJjmeIY2L6pIETE3gJ3Nx8NYTxndQ14Chh U8poz4quf3+cIFakXHCfTbM+gJL05DwFaAvaJ46VSsBdNc4EdkTvkaMqLrx+T2G2 /+M1J5KyEaTWdgnQnsyr =vQZD -----END PGP SIGNATURE----- --FN+gV9K+162wdwwF--