On Thu, Jul 31, 2014 at 03:21:48PM -0700, Jarno Rajahalme wrote: > The definition of memory_order_relaxed included a compiler barrier, > while it is not necessary, and indeed the following text on > atomic_thread_fence and atomic_signal_fence contradicted that. > > memory_order_consume and memory_order_acq_rel are also more thoroughly > described. > > Signed-off-by: Jarno Rajahalme <jrajaha...@nicira.com>
This is great. Here's one spelling fix: diff --git a/lib/ovs-atomic.h b/lib/ovs-atomic.h index d9c506a..064bfcc 100644 --- a/lib/ovs-atomic.h +++ b/lib/ovs-atomic.h @@ -178,7 +178,7 @@ * Prevents movement of memory accesses like an acquire-release barrier, * but whereas acquire-release synchronizes cooperating threads (using * the same atomic variable), sequential-consistency synchronizes the - * whole system, providing a total order for stores an all atomic + * whole system, providing a total order for stores on all atomic * variables. * * The following functions insert explicit barriers. Most of the other atomic Acked-by: Ben Pfaff <b...@nicira.com> _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
