7 ms·

I can't find in documents but does multi-threading effect consistency somehow? Is there a chance that I wouldn't read what I just wrote? I'm talking about singl

I can't find in documents but does multi-threading effect consistency somehow? Is there a chance that I wouldn't read what I just wrote? I'm talking about single node, not about replication, cluster etc. If it provides same consistency, is threading like : sock_read(); lock(datastructures); set x=3; unlock(datastructures); sock_write();

jdsully 5y ago
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 5y ago
  can you share more details about it? I thought locks are slow, but despite locks the is latency halved here.
  - 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 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?
      - jdsully 5y ago
        The 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 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.cpp https://github.com/EQ-Alpha/KeyDB/blob/v6.0.16/src/fastlock....

jdsully 5y ago

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 5y ago
can you share more details about it? I thought locks are slow, but despite locks the is latency halved here.
- 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 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?
    - jdsully 5y ago
      The 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 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.cpp https://github.com/EQ-Alpha/KeyDB/blob/v6.0.16/src/fastlock....