From 6e4f6dfac7d91cad879b36c010b29580e6658855 Mon Sep 17 00:00:00 2001
From: Guido Trotter <ultrotter@google.com>
Date: Tue, 30 Sep 2008 10:21:10 +0000
Subject: [PATCH] locking design: explain use of async mode

Before we were discussing this possible future feature, and its
drawbacks, but not its usefulness. This patch corrects this.

Reviewed-by: iustinp
---
 doc/design-2.0-locking.rst | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/doc/design-2.0-locking.rst b/doc/design-2.0-locking.rst
index 437271411..fd712a440 100644
--- a/doc/design-2.0-locking.rst
+++ b/doc/design-2.0-locking.rst
@@ -155,10 +155,12 @@ operations such as:
 - Try to acquire one of these lock sets and return the first one you were
   able to get (or after a timeout) (select/poll like)
 
-Keep in mind, though, that any operation using the first operation, or setting
-a timeout for the second one, is susceptible to starvation and thus may never
-be able to get the required locks and succeed. Considering this providing/using
-these operations should not be among our first priorities
+These operations can be used to prioritize operations based on available locks,
+rather than making them just blindly queue for acquiring them. The inherent
+risk, though, is that any code using the first operation, or setting a timeout
+for the second one, is susceptible to starvation and thus may never be able to
+get the required locks and complete certain tasks. Considering this
+providing/using these operations should not be among our first priorities.
 
 Locking granularity
 ~~~~~~~~~~~~~~~~~~~
-- 
GitLab