Comments on: Thread Local Storage, part 1: Overview

By: Hugh

Hugh — Fri, 18 Dec 2009 12:56:39 +0000

TLS is one way of providing per-thread non-volatile storage. Other OSs I have worked on (for example Stratus VOS) allowed one to declare per-thread static variables (a bit like _declspec(thread)).

The problem on Windows is performance, the _declspec(thread) seems costly, because each reference to such a var requires an overeahd of getting the TLS info.

I recently created some hand crafted code that we use to replace TLS in our own product’s core library. This API provides the same thing (a per-thread pointer to some scratchpad data) but uses over 50% less CPU time (optimized x64 C code).

Although I’m pleased with the algorithm (and it seems very solid) I do think that Microsoft could have done a better job with this, it really should be a lot less costly.

Thanks for an enlightening post though!

Hugh

By: Bobo

Bobo — Sun, 06 Dec 2009 00:05:14 +0000

It’s not the TEB, it’s the KTHREAD data structure!

By: Nynaeve » Blog Archive » Thread Local Storage, part 8: Wrap-up

Nynaeve » Blog Archive » Thread Local Storage, part 8: Wrap-up — Wed, 31 Oct 2007 16:36:11 +0000

[...] Thread Local Storage, part 1: Overview [...]

By: Nynaeve » Blog Archive » Thread Local Storage, part 2: Explicit TLS

Nynaeve » Blog Archive » Thread Local Storage, part 2: Explicit TLS — Tue, 23 Oct 2007 12:00:32 +0000

[...] Nynaeve Adventures in Windows debugging and reverse engineering. « Thread Local Storage, part 1: Overview [...]

By: Skywing

Skywing — Tue, 23 Oct 2007 04:23:07 +0000

Maybe. It was nothing too special, mostly something to un-break ALT+TAB and fix the habit of the game to do bad things to the display’s gamma correction. It would probably be easier to just recompile the program, as id has released the source code for Quake 3.

By: ac

ac — Tue, 23 Oct 2007 04:10:52 +0000

I hope you will post the hacks you did for Quake 3 aswell sometime in the future

By: Skywing

Skywing — Mon, 22 Oct 2007 19:14:55 +0000

Chris: Yeah, you shouldn’t use TLS in work item routines. More specifically, you can’t assume that two calls to a work item routine will originate from the same thread pool thread, so you can’t store persisted information across work item requests in TLS. (You could conceivably use TLS only while you’re in the context of the current work routine, but this is a fairly narrow use case. It is safer to just avoid TLS entirely in work routines.)

Russell: Yes, although things change a bit in Vista (I’ve got a planned post to talk about how things have evolved with how implicit TLS used to work pre-Vista and how it works post-Vista, so I’ll hold off on saying more until those posts go live).

By: Russell Osterlund

Russell Osterlund — Mon, 22 Oct 2007 18:04:20 +0000

If one takes the time to step through the Window’s loader, you will see that the loader code calls an internal routine, LdrpInitializeTls, before calling DbgBreakPoint (assuming the IsDebuggerPresent flag has been set). LdrpInitializeTls then iterates through each DLL loaded at that point looking for the presence of a TLS directory entry in the PE file. If one is found, only then will the TLS “magic” happen. This is I think the reason for the “annoying limitations” you cited.

By: Chris Clark

Chris Clark — Mon, 22 Oct 2007 17:22:22 +0000

I am not so familiar with TLS but I am wondering about how it works with thread pool threads? With thread pool threads, you are basically running work items on threads that are reused. In this case, I imagine that you cannot use thread local storage to share info “across jobs” because you don’t actually know which thread the next job is going to run on. Is this correct? Not sure it is an interesting thing to talk about and I am certainly not completely informed about it but it popped into mind when reading this. As always, great entry.

By: Marc Sherman

Marc Sherman — Mon, 22 Oct 2007 16:01:15 +0000

Skywing,

This is the clearest description of the fs register I have read. That register was always semi-mysterious to me, but this article has made it very clear, thanks.

Looking forward to the rest of this series.

Marc