Date: Thu, 03 Jan 2002 11:39:20 +1100 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: Bernd Walter <ticso@cicely9.cicely.de> Cc: Michal Mertl <mime@traveller.cz>, Matthew Dillon <dillon@apollo.backplane.com>, Bruce Evans <bde@zeta.org.au>, Mike Smith <msmith@FreeBSD.ORG>, Bernd Walter <ticso@cicely8.cicely.de>, arch@FreeBSD.ORG Subject: Re: When to use atomic_ functions? (was: 64 bit counters) Message-ID: <20020103113919.E561@gsmx07.alcatel.com.au> In-Reply-To: <20020103002521.GB53199@cicely9.cicely.de>; from ticso@cicely9.cicely.de on Thu, Jan 03, 2002 at 01:25:22AM %2B0100 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2002-Jan-03 01:25:22 +0100, Bernd Walter <ticso@cicely9.cicely.de> wrote: >On Thu, Jan 03, 2002 at 09:57:02AM +1100, Peter Jeremy wrote: >> Also, many RISC processors (eg Alpha) don't have locked read-modify- >> write primitives. On the Alpha, you need an instruction sequence: >> loop: load_locked memory->register >> update register >> store_conditional register->memory >> if not success goto loop >> with a few memory barriers added to ensure that the load/store are >> visible to other CPUs. The store_conditional will fail if your CPU >> was interrupted or if another CPU updated an implementation-defined >> region including the specified memory address. (64-bit atomic >> operations on the IA32 use the same approach - using CMPXCHG8B as the >> store_conditional instruction). > >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. Peter 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?20020103113919.E561>