3 ms·
It seems like the thread_local CacheIndex only determines which cache to use, but it doesn't actually guarantee thread safety for concurrent access to the HashL
by jdw64 5mo ago
It seems like the thread_local CacheIndex only determines which cache to use, but it doesn't actually guarantee thread safety for concurrent access to the HashLifeCache itself. What would be a good solution for this?
Should I use a mutex for each cache instance?
As a beginner developer, my guess is that the original author assumes data races won't occur based on the execution timing. However, I'm really not sure if that assumption is actually correct/safe.
- nnevatie 5mo agoIn my view, thread_local is a bit of a code/design red flag. I didn't read the entire code in this case to see whether the thread_local use is warranted or not, though.
- gpderetta 5mo agoa thread_local is just a global variable. Mutable global variables are of course bad, but in this case the threadindex is immutable once created, so it is perfectly fine.
- nnevatie 5mo agoYes, technically it is of course fine, just as a design I find use of thread_local is more of an afterthought than something I'd prefer.