From f368a228d8decd6b5052a770fd071709d1f5e6ec Mon Sep 17 00:00:00 2001
From: 0xflotus <0xflotus@gmail.com>
Date: Wed, 13 Mar 2019 15:14:34 +0100
Subject: [PATCH] fixed guarantees

Former-commit-id: 66f203270862a53b27b18cea8a03999be2262492
---
 README.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/README.md b/README.md
index 49c6373d7..9d89eaa5b 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
 What is KeyDB?
 --------------
 
-KeyDB is a high performance fork of Redis focussing on multithreading, memory efficiency, and high throughput.  In addition to multithreading KeyDB also has features only available in Redis Enterprise such as FLASH storage support, and some not available at all such as direct backup to AWS S3.
+KeyDB is a high performance fork of Redis focusing on multithreading, memory efficiency, and high throughput.  In addition to multithreading KeyDB also has features only available in Redis Enterprise such as FLASH storage support, and some not available at all such as direct backup to AWS S3.
 
 On the same hardware KeyDB can perform twice as many queries per second as Redis, with 60% lower latency.
 
@@ -191,7 +191,7 @@ You'll be able to stop and start KeyDB using the script named
 Multithreading Architecture
 ---------------------------
 
-KeyDB works by running the normal Redis event loop on multiple threads.  Network IO, and query parsing are done concurrently.  Each connection is assigned a thread on accept().  Access to the core hash table is guarded by spinlock.  Because the hashtable access is extremely fast this lock has low contention.  Transactions hold the lock for the duration of the EXEC command.  Modules work in concert with the GIL which is only acquired when all server threads are paused.  This maintains the atomicity gurantees modules expect.
+KeyDB works by running the normal Redis event loop on multiple threads.  Network IO, and query parsing are done concurrently.  Each connection is assigned a thread on accept().  Access to the core hash table is guarded by spinlock.  Because the hashtable access is extremely fast this lock has low contention.  Transactions hold the lock for the duration of the EXEC command.  Modules work in concert with the GIL which is only acquired when all server threads are paused.  This maintains the atomicity guarantees modules expect.
 
 Unlike most databases the core data structure is the fastest part of the system.  Most of the query time comes from parsing the REPL protocol and copying data to/from the network.