Date: Thu, 3 Jan 2002 03:43:13 +0100 From: Bernd Walter <ticso@cicely9.cicely.de> To: arch@FreeBSD.ORG Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <20020103024313.GG53199@cicely9.cicely.de> In-Reply-To: <20020103125839.H561@gsmx07.alcatel.com.au> References: <200201012349.g01NnKA40071@apollo.backplane.com> <Pine.BSF.4.41.0201021003580.18429-100000@prg.traveller.cz> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <ticso@cicely9.cicely.de> wrote: > >On Thu, Jan 03, 2002 at 11:39:20AM +1100, Peter Jeremy wrote: > >> On 2002-Jan-03 01:25:22 +0100, Bernd Walter <ticso@cicely9.cicely.de> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020103024313.GG53199>