thread-local storage

Sometimes you want a variable that every thread can refer to by the same name, but where each thread quietly gets its own private copy. Thread-local storage gives you exactly that. Picture a hotel where every room has a thing labelled 'minibar': the label is the same in every room, but each guest's minibar is their own - what one guest takes does not touch another's. A thread-local variable works the same way: one name, but a separate, independent box per thread.

Concretely, a normal global variable is one box shared by all threads (and therefore shared mutable state, with all its hazards). A thread-local variable is declared so the runtime gives each thread its own instance of it; thread A's copy and thread B's copy live at different addresses, and writing one never affects the other. In C11 you mark such a variable with the _Thread_local keyword (C++ uses thread_local); older code uses compiler extensions like __thread. Each thread's copy is created when the thread starts and lives as long as that thread. So you get the convenience of a global - reachable from any function without passing it around - without the sharing, because it is not actually shared.

Why it is useful: thread-local storage is one of the cleanest cures for shared mutable state, because it removes the 'shared' leg entirely. The classic real example is errno: many library functions report errors through errno, and if it were one shared global, two threads' error codes would clobber each other - so on threaded systems errno is thread-local, giving each thread its own. The same trick suits per-thread scratch buffers, counters you total up at the end, or any state that is logically 'this thread's own'. The trade-off is that thread-local data is genuinely separate: it cannot be used to communicate between threads, and each copy costs a little memory.