3 ms·
Author here. We added fine grain locking to the redis codebase. The goal is to expand what’s concurrent over time. Currently network IO and query parsing are m
by jdsully 8y ago
Author here. We added fine grain locking to the redis codebase. The goal is to expand what’s concurrent over time.
Currently network IO and query parsing are multithreaded. Access to the core hash table is under lock. However network IO and query parsing take up most of the time in Redis queries. Hash tables are pretty fast. The goal is to add a reader/writer lock here in the future.
The lock itself is also interesting. We used a ticket lock which is a variant of a spin lock. This ensures fair locking and reduces the variance in latency dramatically. Standard POSIX locks are too slow.
- rbranson 8y agoI've always wondered what the best concurrency approach would be for a fully compatible fully concurrent Redis. The single-threaded nature makes it naturally expose some strict semantics to the user, which is tricky. What are you planning on doing to push past the global lock for the hashtable?
- BubRoss 8y agohttps://news.ycombinator.com/item?id=19369794 https://news.ycombinator.com/item?id=19369794 This is an example that is completely lock free.