4 ms·
KeyDB uses a custom lock I wrote called the “fastlock”. At its core it’s a ticket lock with some tweaks to better tune it to KeyDB. When uncontested it’s a sing
by jdsully 5y ago
KeyDB uses a custom lock I wrote called the “fastlock”. At its core it’s a ticket lock with some tweaks to better tune it to KeyDB. When uncontested it’s a single atomic increment. When contested ownership changes extremely fast. If we spin too long the thread will sleep although we wait much longer than any other lock you’ll find.
When I first tried making KeyDB I used posix locks. Those were way too slow.
- avinassh 5y agoI am too newb to understand half of those terms :) Do you have any recommendations for a reading material to understand the underlying concepts?
- jdsully 5y agoThe wikipedia page on ticket locks has a good overview: https://en.wikipedia.org/wiki/Ticket_lock https://en.wikipedia.org/wiki/Ticket_lock Generally speaking you don't want to be dealing with this stuff unless you really have to. For 99.999% of people the locking primitives that come with your programming language are good enough.
- avinassh 5y agoI went through the wiki, certainly it was interesting. I believe the implementation is at fastlock.cpp [0], I will go through it. You said earlier: > If we spin too long the thread will sleep although we wait much longer than any other lock you’ll find. Did you do any tweaks to mitigate this? > Generally speaking you don't want to be dealing with this stuff unless you really have to. Ofcourse. I am just way too curious and excited to learn about these! [0] - https://github.com/EQ-Alpha/KeyDB/blob/v6.0.16/src/fastlock.cpp https://github.com/EQ-Alpha/KeyDB/blob/v6.0.16/src/fastlock....