Hacker News new | ask | show | jobs
by avinassh 1874 days ago
can you share more details about it? I thought locks are slow, but despite locks the is latency halved here.
1 comments
jdsully 1874 days 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.

link
avinassh 1873 days ago
I am too newb to understand half of those terms :)

Do you have any recommendations for a reading material to understand the underlying concepts?

link
jdsully 1873 days ago
The wikipedia page on ticket locks has a good overview: 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.

link
avinassh 1873 days ago
I 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....

link