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, > > > > > > 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: > > > > > > #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)) > > > > > > 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. > > > > 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. > > 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.
> > > 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. > > Ah, thanks, that's what I was interested in knowing. > > > > > > > (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 not. > > > As long as it's unique for each thread, and static for the lifetime > > > of the thread, that's fine.) > > > > > > The "am I the main thread?" comparison is made every ~50-100 opcodes, > > > which is why it needs to have the lowest overhead possible. > > > 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. > > 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). > > Thanks Konstantin, very helpful. > > Trent.
pgpm7aloC53Ee.pgp
Description: PGP signature
