[jdsully]

Yea that was roughly KeyDB’s original design. There’s some nuance in the locking like ensuring it’s both fair and fast so P99 latency doesn’t get out of control.

In the Enterprise codebase we can take snapshots which lets us do reads without the lock but it’s a bit of work to enable for commands so it only applies to KEYS and SCAN at the moment.

[avinassh]

can you share more details about it? I thought locks are slow, but despite locks the is latency halved here.

[jdsully]

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]

I am too newb to understand half of those terms :)

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

[jdsully]

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.

[avinassh]

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....