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.
It's extremely inefficient, using pointers to neighboring cells.
If you want to handle the grid edges (whether for a wrap-around "infinite" grid, or not) without too much special code, then leave a 1-cell border around the grid and fill this with the appropriate data (empty cells, or wraparound cells). If you really want to be efficient then just write the special-case edge code.
"I had heard the rumors that C++ was a scary language filled with footguns and segmentation faults, but I had never given it a fair chance myself" - props for this. There's too much hearsay in software engineering.
7 comments
[ 4.6 ms ] story [ 24.3 ms ] threadShould 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.
If you want to handle the grid edges (whether for a wrap-around "infinite" grid, or not) without too much special code, then leave a 1-cell border around the grid and fill this with the appropriate data (empty cells, or wraparound cells). If you really want to be efficient then just write the special-case edge code.