From owner-freebsd-smp Wed Jan 3 10:50:53 2001 From owner-freebsd-smp@FreeBSD.ORG Wed Jan 3 10:50:50 2001 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from meow.osd.bsdi.com (meow.osd.bsdi.com [204.216.28.88]) by hub.freebsd.org (Postfix) with ESMTP id D49DC37B400 for ; Wed, 3 Jan 2001 10:50:50 -0800 (PST) Received: from laptop.baldwin.cx (john@jhb-laptop.osd.bsdi.com [204.216.28.241]) by meow.osd.bsdi.com (8.11.1/8.9.3) with ESMTP id f03InlG28097; Wed, 3 Jan 2001 10:49:47 -0800 (PST) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.4.0 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200101031839.LAA08694@fast.cs.utah.edu> Date: Wed, 03 Jan 2001 10:50:28 -0800 (PST) From: John Baldwin To: Kevin Van Maren Subject: Re: atomic increment? Cc: smp@FreeBSD.org Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 03-Jan-01 Kevin Van Maren wrote: >> > load/cmpxchg code shouldn't be too hard: you just need a scratch >> > register, set it equal to eax (and ANY garbage value), and LOCK >> > cmpxchg it with the address. The read value is placed in (part of, >> > for 8/16 bit ops) eax. One register-register mov and one atomic >> > memory RMW cycle (which works because Intel always does the RMW >> > cycle; it writes back the original value if the cmp fails, and >> > eax will always contain the value that was in memory). Should >> > be a pretty efficient inline asm. >> > >> > Do you want me to send in a patch? >> >> If you'd like, sure. I was planning to use a lock'd xchgl for the store, >> but >> wasn't sure if that would work properly. Trying to use a cmpxchgl for the >> store would get ugly as you would have to do a loop until it actually did a >> store. Yuck. > > For the store you'd want to do a straight xchgl, which will even > return the old value (see my previous message about adding variants > that return the old values...). > We can even save a byte in the code by not using the LOCK prefix, since > lock is always asserted for xchg. Sounds good. > Hmmm. Actually, with writes being visible in-order on IA32, even on > SMP, the store's release semantics may be okay as is? Okay, now I'M > confusing myself. It won't provide memory fence semantics or strong > ordering, but that isn't required by a store_rel. If the PPro retires > instructions in order, and doesn't "execute" writes until they are > retired, then the write can't complete before a previous read, so the > current store code already has release semantics. Right? > On IA64, a release doesn't have to occur before a following acquire; > so we can allow a subsequent read to "pass" this store, as long as > the CPU executes the store after all previos instructions. store_rel still needs to act as a memory barrier to guarantee that any pending reads/writes are completed before the store in question so that all "protected" accesses are performed while the lock is still held. > Certainly the read needs to be changed to provide acquire semantics. Yes. > I'll look at writing a patch when I get off work tonight... > > Maybe I'll look at writing 64-bit operations using cmpxchg8b too (but > that requires a Pentium -- and there were some dual 486 PCs built, not > that we'd ever support the second CPU on them anyway). On uni-procs, > we can disable interrupts and be okay. You can assume a Pentium for the 64-bit stuff and use cmpxchg8b, I don't foresee us supporting MP on [34]86. This is something that has been sort of on my todo list, but I'm not entirely sure how useful it will be. > Kevin -- John Baldwin -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message