Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Jan 2013 23:43:32 +0200
From:      Konstantin Belousov <kostikbel@gmail.com>
To:        Trent Nelson <trent@snakebite.org>
Cc:        "freebsd-hackers@freebsd.org" <freebsd-hackers@freebsd.org>
Subject:   Re: Getting the current thread ID without a syscall?
Message-ID:  <20130115214332.GE2522@kib.kiev.ua>
In-Reply-To: <20130115213513.GA53047@snakebite.org>
References:  <20130115205403.GA52904@snakebite.org> <20130115211641.GC2522@kib.kiev.ua> <20130115213513.GA53047@snakebite.org>

next in thread | previous in thread | raw e-mail | index | archive | help

--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 <intrin.h>
> > > #       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--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130115214332.GE2522>