Messages in this thread Patch in this message | | | From | "Paul E. McKenney" <> | Subject | [PATCH memory-barriers.txt 7/7] Documentation,barriers: Mention smp_cond_acquire() | Date | Tue, 12 Apr 2016 08:52:55 -0700 |
| |
From: Davidlohr Bueso <dave@stgolabs.net>
... do this next to smp_load_acquire when first mentioning ACQUIRE. While this call is briefly explained and ctrl dependencies are mentioned later, it does not hurt the reader.
Signed-off-by: Davidlohr Bueso <dbueso@suse.de> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- Documentation/memory-barriers.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 7133626a61d0..a9454b1c73bd 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -431,8 +431,9 @@ And a couple of implicit varieties: This acts as a one-way permeable barrier. It guarantees that all memory operations after the ACQUIRE operation will appear to happen after the ACQUIRE operation with respect to the other components of the system. - ACQUIRE operations include LOCK operations and smp_load_acquire() - operations. + ACQUIRE operations include LOCK operations and both smp_load_acquire() + and smp_cond_acquire() operations. The later builds the necessary ACQUIRE + semantics from relying on a control dependency and smp_rmb(). Memory operations that occur before an ACQUIRE operation may appear to happen after it completes. -- 2.5.2
| |