From owner-freebsd-arch Wed Jan 2 18:46:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from srv1.cosmo-project.de (srv1.cosmo-project.de [213.83.6.106]) by hub.freebsd.org (Postfix) with ESMTP id 0F59F37B416 for ; Wed, 2 Jan 2002 18:46:49 -0800 (PST) Received: (from uucp@localhost) by srv1.cosmo-project.de (8.11.6/8.11.6) with UUCP id g032klS11126 for arch@FreeBSD.ORG; Thu, 3 Jan 2002 03:46:47 +0100 (CET) (envelope-from ticso@cicely9.cicely.de) Received: from mail.cicely.de (cicely20.cicely.de [10.1.1.22]) by cicely5.cicely.de (8.12.1/8.12.1) with ESMTP id g032hHtx047219 for ; Thu, 3 Jan 2002 03:43:17 +0100 (CET)?g (envelope-from ticso@cicely9.cicely.de) Received: from cicely9.cicely.de (cicely9.cicely.de [10.1.7.11]) by mail.cicely.de (8.11.0/8.11.0) with ESMTP id g032hGW13211 for ; Thu, 3 Jan 2002 03:43:16 +0100 (CET) Received: (from ticso@localhost) by cicely9.cicely.de (8.11.6/8.11.6) id g032hD962782 for arch@FreeBSD.ORG; Thu, 3 Jan 2002 03:43:13 +0100 (CET) (envelope-from ticso) Date: Thu, 3 Jan 2002 03:43:13 +0100 From: Bernd Walter To: arch@FreeBSD.ORG Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <20020103024313.GG53199@cicely9.cicely.de> 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> <20020103125839.H561@gsmx07.alcatel.com.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020103125839.H561@gsmx07.alcatel.com.au> User-Agent: Mutt/1.3.24i X-Operating-System: FreeBSD cicely9.cicely.de 5.0-CURRENT alpha 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 On Thu, Jan 03, 2002 at 12:58:39PM +1100, Peter Jeremy wrote: > [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. On alpha the barriers don't control memory content - only order. In fact if you protect a data structure with ldx_l/stx_c/mb your data writen may still be in the CPU cache after releasing the lock. stx_c places a lock on the cache line if it succeds but may not write any memory. You can read this in chapter 4.6 in the Alpha 21264 Microprocessor Hardware Reference Manual. The mb instructions are needed to get the protected data over the coherency point in case the lock is handed to another CPU. Hardware don't use atomic_acq so it needs other mechanisms. Anothere point is that non read-modify-write based atomic_rel functions don't need to use locked instructions. E.g. atomic_store_rel_ptr used by MI mutex functions. -- B.Walter COSMO-Project http://www.cosmo-project.de ticso@cicely.de Usergroup info@cosmo-project.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message