From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 7 Mar 2002 02:34:06 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 7 Mar 2002 02:33:56 -0500 Received: from sydney1.au.ibm.com ([202.135.142.193]:20997 "EHLO haven.ozlabs.ibm.com") by vger.kernel.org with ESMTP id ; Thu, 7 Mar 2002 02:33:44 -0500 From: Rusty Russell To: torvalds@transmeta.com Cc: linux-kernel@vger.kernel.org Subject: [PATCH] TRIVIAL I: 2.5.6-pre3. Documentation Date: Thu, 07 Mar 2002 18:37:02 +1100 Message-Id: Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Linus, please apply. atomic ops are *not* barriers any more. Sebastian Wilhelmi : Re: Question on your "Unreliable Guide To Locking": > Yes, this is no longer true. The modern assumptions are that they are > not barriers. diff -urN -I \$.*\$ --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal linux-2.5.6-pre3/Documentation/DocBook/kernel-locking.tmpl trivial-2.5.6-pre3/Documentation/DocBook/kernel-locking.tmpl --- linux-2.5.6-pre3/Documentation/DocBook/kernel-locking.tmpl Sun May 20 10:43:05 2001 +++ trivial-2.5.6-pre3/Documentation/DocBook/kernel-locking.tmpl Thu Mar 7 18:20:33 2002 @@ -788,8 +788,18 @@ - Note that the atomic operations are defined to act as both - read and write barriers on all platforms. + Note that the atomic operations do in general not act as memory + barriers. Instead you can insert a memory barrier before or + after atomic_inc() or + atomic_dec() by inserting + smp_mb__before_atomic_inc(), + smp_mb__after_atomic_inc(), + smp_mb__before_atomic_dec() or + smp_mb__after_atomic_dec() + respectively. The advantage of using those macros instead of + smp_mb() is, that they are cheaper on some + platforms. + -- Anyone who quotes me in their sig is an idiot. -- Rusty Russell.