From owner-freebsd-arch Wed Jan 2 17:58:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from netau1.alcanet.com.au (ntp.alcanet.com.au [203.62.196.27]) by hub.freebsd.org (Postfix) with ESMTP id 80D7F37B41C for ; Wed, 2 Jan 2002 17:58:54 -0800 (PST) Received: from mfg1.cim.alcatel.com.au (mfg1.cim.alcatel.com.au [139.188.23.1]) by netau1.alcanet.com.au (8.9.3 (PHNE_22672)/8.9.3) with ESMTP id MAA12361; Thu, 3 Jan 2002 12:58:42 +1100 (EDT) Received: from gsmx07.alcatel.com.au by cim.alcatel.com.au (PMDF V5.2-32 #37641) with ESMTP id <01KCMVNKJH00VFM67E@cim.alcatel.com.au>; Thu, 3 Jan 2002 12:57:49 +1100 Received: (from jeremyp@localhost) by gsmx07.alcatel.com.au (8.11.6/8.11.6) id g031wdM04443; Thu, 03 Jan 2002 12:58:40 +1100 Content-return: prohibited Date: Thu, 03 Jan 2002 12:58:39 +1100 From: Peter Jeremy Subject: Re: When to use atomic_ functions? (was: 64 bit counters) In-reply-to: <20020103011645.GE53199@cicely9.cicely.de>; from ticso@cicely9.cicely.de on Thu, Jan 03, 2002 at 02:16:45AM +0100 To: Bernd Walter Cc: arch@FreeBSD.ORG Mail-Followup-To: Bernd Walter , arch@FreeBSD.ORG Message-id: <20020103125839.H561@gsmx07.alcatel.com.au> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.2.5i References: <200201012349.g01NnKA40071@apollo.backplane.com> <20020103095701.B561@gsmx07.alcatel.com.au> <20020103002521.GB53199@cicely9.cicely.de> <20020103113919.E561@gsmx07.alcatel.com.au> <20020103011645.GE53199@cicely9.cicely.de> Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [Pruning CC list] On 2002-Jan-03 02:16:45 +0100, Bernd Walter wrote: >On Thu, Jan 03, 2002 at 11:39:20AM +1100, Peter Jeremy wrote: >> On 2002-Jan-03 01:25:22 +0100, Bernd Walter wrote: >> >My Alpha Architecture Handbook says that the barrier is unneeded. >> >I have no clue why they are there. >> >> You're right. Version 2, section 5.5 shows that they aren't needed >> when a single datum is being atomically updated (as needed here). >> They're only needed where the atomic operation is seizing a lock so >> that a larger structure can be atomically updated. > >I will do this change localy a send a patch to -alpha. >Maybe we can also remove the barriers for rel/acq in the non SMP case, >but I could also be wrong if drivers depend on them. My understanding is that barriers are needed when it's necessary to control the content of main memory or read/write ordering, as seen by something other than the current CPU. In a UP system, this means that barriers are still needed for I/O (both PIO and DMA). Based on atomic(9), I think the barriers are still necessary for acq/rel - which are essentially acquiring/releasing locks on larger data structures. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message