From d04dd21a0b804bc5acb8d3ea1e25daa7dbc97e25 Mon Sep 17 00:00:00 2001 From: kib Date: Sat, 20 Jun 2015 17:18:46 +0000 Subject: The barriers, provided by _acq and _rel atomics, are acquire and release barriers, not read and write barriers. They fence all memory accesses from the respective side, not limited by the kind of operation. Reviewed by: jhb Sponsored by: The FreeBSD Foundation MFC after: 1 week --- share/man/man9/atomic.9 | 10 +++++++--- 1 file changed, 7 insertions(+), 3 deletions(-) (limited to 'share') diff --git a/share/man/man9/atomic.9 b/share/man/man9/atomic.9 index a9ce842..cc353cd 100644 --- a/share/man/man9/atomic.9 +++ b/share/man/man9/atomic.9 @@ -23,7 +23,7 @@ .\" .\" $FreeBSD$ .\" -.Dd August 20, 2013 +.Dd June 20, 2015 .Dt ATOMIC 9 .Os .Sh NAME @@ -123,7 +123,9 @@ The first form just performs the operation without any explicit barriers. The second form uses a read memory barrier, and the third variant uses a write memory barrier. .Pp -The second variant of each operation includes a read memory barrier. +The second variant of each operation includes an +.Em acquire +memory barrier. This barrier ensures that the effects of this operation are completed before the effects of any later data accesses. As a result, the operation is said to have acquire semantics as it acquires a @@ -137,7 +139,9 @@ For example, to subtract two integers ensuring that any later writes will happen after the subtraction is performed, use .Fn atomic_subtract_acq_int . .Pp -The third variant of each operation includes a write memory barrier. +The third variant of each operation includes a +.Em release +memory barrier. This ensures that all effects of all previous data accesses are completed before this operation takes place. As a result, the operation is said to have release semantics as it releases -- cgit v1.1