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>

Documentation/RCU/Design/Requirements/Requirements.html

@@ -1494,6 +1494,14 @@ <h3><a name="Composability">Composability</a></h3>
 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

Documentation/RCU/Design/Requirements/Requirements.htmlx

@@ -1653,6 +1653,14 @@ in RCU implicitly splitting the enclosing RCU read-side critical
 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