{"id":3541,"date":"2012-05-03T12:11:00","date_gmt":"2012-05-03T12:11:00","guid":{"rendered":"https:\/\/test.simple-talk.com\/uncategorized\/subterranean-il-the-threadlocal-type\/"},"modified":"2021-04-29T15:30:53","modified_gmt":"2021-04-29T15:30:53","slug":"subterranean-il-the-threadlocal-type","status":"publish","type":"post","link":"https:\/\/www.red-gate.com\/simple-talk\/blogs\/subterranean-il-the-threadlocal-type\/","title":{"rendered":"Subterranean IL: The ThreadLocal type"},"content":{"rendered":"

I came across ThreadLocal<T><\/code> while I was researching ConcurrentBag<\/code>. To look at it, it doesn’t really make much sense. What’s all those extra Cn<\/code> classes doing in there? Why is there a GenericHolder<T,U,V,W><\/code> class? What’s going on? However, digging deeper, it’s a rather ingenious solution to a tricky problem.<\/p>\n

Thread statics<\/h4>\n

Declaring that a variable is thread static, that is, values assigned and read from the field is specific to the thread doing the reading, is quite easy in .NET:<\/p>\n

[ThreadStatic]\nprivate static string s_ThreadStaticField;<\/pre>\n
ThreadStaticAttribute<\/code> is not a pseudo-custom attribute<\/a>; it is compiled as a normal attribute, but the CLR has in-built magic, activated by that attribute, to redirect accesses to the field based on the executing thread’s identity.<\/p>\n
TheadStaticAttribute<\/code> provides a simple solution when you want to use a single field as thread-static. What if you want to create an arbitary number of thread static variables at runtime? Thread-static fields can only be declared, and are fixed, at compile time. Prior to .NET 4, you only had one solution – thread local data slots<\/a>. This is a lesser-known function of Thread<\/code> that has existed since .NET 1.1:<\/p>\n
LocalDataStoreSlot threadSlot = Thread.AllocateNamedDataSlot(\"slot1\");\n\nstring value = \"foo\";\nThread.SetData(threadSlot, value);\n\nstring gettedValue = (string)Thread.GetData(threadSlot);<\/pre>\n
Each instance of LocalStoreDataSlot<\/code> mediates access to a single slot, and each slot acts like a separate thread-static field.<\/p>\n
As you can see, using thread data slots is quite cumbersome. You need to keep track of LocalDataStoreSlot<\/code> objects, it’s not obvious how instances of LocalDataStoreSlot<\/code> correspond to individual thread-static variables, and it’s not type safe. It’s also relatively slow and complicated; the internal implementation consists of a whole series of classes hanging off a single thread-static field in Thread<\/code> itself, using various arrays, lists, and locks for synchronization. ThreadLocal<T><\/code> is far simpler and easier to use.<\/p>\n
ThreadLocal<\/h4>\n
ThreadLocal<\/code> provides an abstraction around thread-static fields that allows it to be used just like any other class; it can be used as a replacement for a thread-static field, it can be used in a List<ThreadLocal<T>><\/code>, you can create as many as you need at runtime. So what does it do? It can’t just have an instance-specific thread-static field, because thread-static fields have to be declared as static<\/code>, and so shared between all instances of the declaring type. There’s something else going on here.<\/p>\n
The values stored in instances of ThreadLocal<T><\/code> are stored in instantiations of the GenericHolder<T,U,V,W><\/code> class, which contains a single ThreadStatic<\/code> field (s_value<\/code>) to store the actual value. This class is then instantiated with various combinations of the Cn<\/code> types for generic arguments.<\/p>\n
In .NET, each separate instantiation of a generic type has its own static state. For example, GenericHolder<int,C0,C1,C2><\/code> has a completely separate s_value<\/code> field to GenericHolder<int,C1,C14,C1><\/code>. This feature is (ab)used by ThreadLocal<\/code> to emulate instance thread-static fields.<\/p>\n
Every time an instance of ThreadLocal<\/code> is constructed, it is assigned a unique number from the static s_currentTypeId<\/code> field using Interlocked.Increment<\/code>, in the FindNextTypeIndex<\/code> method. The hexadecimal representation of that number then defines the specific Cn<\/code> types that instantiates the GenericHolder<\/code> class. That instantiation is therefore ‘owned’ by that instance of ThreadLocal<\/code>.<\/p>\n
This gives each instance of ThreadLocal<\/code> its own ThreadStatic<\/code> field through a specific unique instantiation of the GenericHolder<\/code> class. Although GenericHolder<\/code> has four type variables, the first one is always instantiated to the type stored in the ThreadLocal<T><\/code>. This gives three free type variables, each of which can be instantiated to one of 16 types (C0<\/code> to C15<\/code>). This puts an upper limit of 4096 (163) on the number of ThreadLocal<T><\/code> instances that can be created for each value of T. That is, there can be a maximum of 4096 instances of ThreadLocal<string><\/code>, and separately a maximum of 4096 instances of ThreadLocal<object><\/code>, etc.<\/p>\n
However, there is an upper limit of 16384 enforced on the total number of ThreadLocal<\/code> instances in the AppDomain. This is to stop too much memory being used by thousands of instantiations of GenericHolder<T,U,V,W><\/code>, as once a type is loaded into an AppDomain it cannot be unloaded, and will continue to sit there taking up memory until the AppDomain is unloaded. The total number of ThreadLocal<\/code> instances created is tracked by the ThreadLocalGlobalCounter<\/code> class.<\/p>\n
So what happens when either limit is reached? Firstly, to try and stop this limit being reached, it recycles GenericHolder<\/code> type indexes of ThreadLocal<\/code> instances that get disposed using the s_availableIndices<\/code> concurrent stack. This allows GenericHolder<\/code> instantiations of disposed ThreadLocal<\/code> instances to be re-used. But if there aren’t any available instantiations, then ThreadLocal<\/code> falls back on a standard thread local slot using TLSHolder<\/code>. This makes it very important to dispose of your ThreadLocal<\/code> instances if you’ll be using lots of them, so the type instantiations can be recycled.<\/p>\n
The previous way of creating arbitary thread-static variables, thread data slots, was slow, clunky, and hard to use. In comparison, ThreadLocal<\/code> can be used just like any other type, and each instance appears from the outside to be a non-static thread-static variable. It does this by using the CLR type system to assign each instance of ThreadLocal<\/code> its own instantiated type containing a thread-static field, and so delegating a lot of the bookkeeping that thread data slots had to do to the CLR type system itself! That’s a very clever use of the CLR type system.<\/p>\n","protected":false},"excerpt":{"rendered":"
I came across ThreadLocal<T> while I was researching ConcurrentBag. To look at it, it doesn’t really make much sense. What’s all those extra Cn classes doing in there? Why is there a GenericHolder<T,U,V,W> class? What’s going on? However, digging deeper, it’s a rather ingenious solution to a tricky problem. Thread statics Declaring that a variable……<\/p>\n","protected":false},"author":186659,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[143538,2],"tags":[],"coauthors":[],"class_list":["post-3541","post","type-post","status-publish","format-standard","hentry","category-dotnet-development","category-blogs"],"acf":[],"_links":{"self":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3541","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/users\/186659"}],"replies":[{"embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/comments?post=3541"}],"version-history":[{"count":2,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3541\/revisions"}],"predecessor-version":[{"id":75602,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/posts\/3541\/revisions\/75602"}],"wp:attachment":[{"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/media?parent=3541"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/categories?post=3541"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/tags?post=3541"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.red-gate.com\/simple-talk\/wp-json\/wp\/v2\/coauthors?post=3541"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}