documentation: Composability analogies

This commit expands on RCU's composability by comparing it to that of
transactional memory and of locking.

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>

1 files changed, 8 insertions, 0 deletions

diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
index cc5b587c0ec5..105247149975 100644
--- a/Documentation/RCU/Design/Requirements/Requirements.html
+++ b/Documentation/RCU/Design/Requirements/Requirements.html
@@ -1495,6 +1495,14 @@ section, neither of which is conducive to a long-lived and prosperous
 kernel.
 
 <p>
+It is worth noting that RCU is not alone in limiting composability.
+For example, many transactional-memory implementations prohibit
+composing a pair of transactions separated by an irrevocable
+operation (for example, a network receive operation).
+For another example, lock-based critical sections can be composed
+surprisingly freely, but only if deadlock is avoided.
+
+<p>
 In short, although RCU read-side critical sections are highly composable,
 care is required in some situations, just as is the case for any other
 composable synchronization mechanism.