Date: Fri, 9 Feb 2001 03:08:19 +0100 From: Bernd Walter <ticso@cicely5.cicely.de> To: freebsd-current@FreeBSD.ORG Subject: Re: atomic_ question Message-ID: <20010209030819.C81461@cicely5.cicely.de> In-Reply-To: <20010209110004.D90937@gsmx07.alcatel.com.au>; from peter.jeremy@alcatel.com.au on Fri, Feb 09, 2001 at 11:00:04AM %2B1100 References: <20010208182106.B80741@cicely5.cicely.de> <20010209075749.Z90937@gsmx07.alcatel.com.au> <20010208222131.D81067@cicely5.cicely.de> <20010209110004.D90937@gsmx07.alcatel.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 09, 2001 at 11:00:04AM +1100, Peter Jeremy wrote: > On 2001-Feb-08 22:21:32 +0100, Bernd Walter <ticso@cicely5.cicely.de> wrote: > >On sparcv8 you don't have an operation doing conditionaly stores and > >you don't have RMW operations. > >The only way to do is to have a global lock variable on which you spin > >until the current client finishes. > > The SPARC architecture supports SMP so there must be some > synchronisation primitive that works between processors (disabling > interrupts only works on the current processor). Normally the same > primitive can be used to synchronise accesses within the same > processor. I know the older SPARC's had a test-and-set instruction > which was locked RMW - there must be something similar in v8 and v9. sparcv8 has: LDSTUB - which is a atomic load into register and store 0xff SWAP - which exchanges a register with memory atomicly sparcv9 has additionaly the Comapare And Set (CAS) operation which makes it similar in use as alpha. I can't speak for sparcv7 and older but maybe you are refering to sparcv9 with it's CAS operation as an "older" SPARC or have a vendor specific extension in mind. Disabling interrupts will work fine because the reason is to avoid deadlocks. The only thing needed is that the processor holding the lock can't be interrupted until it's finished. If another CPU want's the same lock it can spinwait because the other CPU still gets the chance to release the lock. No doubt the available primitives are enough - but I wanted to know if its neccessary to go the complete ugly way. The sparv8 way for FreeBSDs atomic_ is now clear to me: disable ints for the CPU in question fetch the lock do the real work wmb unlock restore ints Thank you all for making this clear. -- 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-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010209030819.C81461>