Repository navigation
readIndex in RedisCache is not atomic — data race between writeBuffer and copyReadBuffer #86
Description
Activity
- added a commit that references this issue
on Mar 13, 2026 The race described here can't actually happen:
writeBufferruns only from this cache's reader callback;ThreadPool::jobpins each stream key to one worker (hasher(name) % num);- so lines 34 and 41 always run on the same thread.
TSan reports nothing at those lines, on
mainor at the #111 stack head.The race TSan does find in RedisCache is
copyReadBufferfilling the cache while holding only the shared lock. Concurrent readers then writelastWriteand assign into the same buffer vector, including during reallocation. I've filed that as #120; this issue could be re-scoped or closed in favour of it.
Description
In
RedisCache.hpp:26,readIndexis a plainint. It is written under the exclusive lock inwriteBuffer(line 41), but read outside any lock on line 34:If
writeBufferis called from the reader callback thread while another thread holds the shared lock for reading, the read on line 34 races with the write on line 41.Severity
Medium
Suggested Fix
Make
readIndexanstd::atomic<int>, or access it under the mutex consistently.