3 ms·

I have done plenty with threads but never used thread-local storage except when forced to by some other library using it. To me it seems like a bolted-on monstr

I have done plenty with threads but never used thread-local storage except when forced to by some other library using it. To me it seems like a bolted-on monstrosity that provides thread safety to thread-naive code after the fact. Am I missing something? Is this a good solution to some problem I haven't encountered? Are there situations where the performance of TLS is better than some other solution?

electricshampo1 6y ago
One use is scalable counting: Is Parallel Programming Hard, And, If So, What Can You Do About It? https://cdn.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html https://cdn.kernel.org/pub/linux/kernel/people/paulmck/perfb...
- jstrong 6y ago
  I read the section in that book about storing each thread's count in a TLS variable, and I think the root of the confusion is related to how C vs. Rust (the language I use and learned how to write multithreaded code in) deal with threads. if I wanted to store a per-thread count in rust, it would make zero sense to use TLS for that, it would just be on the stack in the context of the thread's lexical scope: let mut threads = Vec::new(); let global_count = Arc::new(AtomicUsize::new(0)); for _ in 0..n_threads { threads.push(std::thread::spawn({ let global_count = global_count.clone(); move || { let mut thread_count = 0; for _ in some_iteration { thread_count += 1; } global_count.fetch_add(thread_count, Ordering::Release); } }); } for handle in threads { let _ = handle.join().unwrap(); } println!("global count = {}", global_count.load(Ordering::Acquire)); that is a form of "thread-local storage", I guess, but does not involve any of the TLS primitives.
CodesInChaos 6y ago
I've used it to store the state of a global RNG. Thread local state is faster than locking a shared RNG and the observable behaviour is the same. For high quality code you often pass around the RNG instance explicitly (improves testability), but often I just want a random number without bothering with explicit state management.
- jstrong 6y ago
  that seems pretty legit.

electricshampo1 6y ago

One use is scalable counting: Is Parallel Programming Hard, And, If So, What Can You Do About It? https://cdn.kernel.org/pub/linux/kernel/people/paulmck/perfbook/perfbook.html https://cdn.kernel.org/pub/linux/kernel/people/paulmck/perfb...

jstrong 6y ago
I read the section in that book about storing each thread's count in a TLS variable, and I think the root of the confusion is related to how C vs. Rust (the language I use and learned how to write multithreaded code in) deal with threads. if I wanted to store a per-thread count in rust, it would make zero sense to use TLS for that, it would just be on the stack in the context of the thread's lexical scope: let mut threads = Vec::new(); let global_count = Arc::new(AtomicUsize::new(0)); for _ in 0..n_threads { threads.push(std::thread::spawn({ let global_count = global_count.clone(); move || { let mut thread_count = 0; for _ in some_iteration { thread_count += 1; } global_count.fetch_add(thread_count, Ordering::Release); } }); } for handle in threads { let _ = handle.join().unwrap(); } println!("global count = {}", global_count.load(Ordering::Acquire)); that is a form of "thread-local storage", I guess, but does not involve any of the TLS primitives.

CodesInChaos 6y ago

I've used it to store the state of a global RNG. Thread local state is faster than locking a shared RNG and the observable behaviour is the same. For high quality code you often pass around the RNG instance explicitly (improves testability), but often I just want a random number without bothering with explicit state management.

jstrong 6y ago
that seems pretty legit.