Messages in this thread Patch in this message | | | From | Davidlohr Bueso <> | Subject | [PATCH] Documentation,barriers: Mention smp_cond_acquire() | Date | Mon, 21 Mar 2016 14:07:19 -0700 |
| |
... 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> --- 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 3729cbe60e41..2b5ea9d01a8f 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -430,8 +430,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.1.4
| |