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