Date: Wed, 03 Jan 2001 08:44:23 -0800 (PST) From: John Baldwin <jhb@freebsd.org> To: Kevin Van Maren <vanmaren@fast.cs.utah.edu> Cc: smp@freebsd.org Subject: Re: atomic increment? Message-ID: <XFMail.010103084423.jhb@FreeBSD.org> In-Reply-To: <200101030405.VAA16941@fast.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 03-Jan-01 Kevin Van Maren wrote: > John, > >> > Note that the only atomic_load and atomic_store primities are those that >> > include memory barriers (and I think they are broken on the x86 for that >> > matter; they need to use a lock'd cmpxchgl in the load case and a lock'd >> > xchgl >> > in the store case I think.) > > Okay, I finally got it! > > These are also in the man page: >> The atomic_load() functions always have acquire semantics. > along with an example using atomic_load() instead of atomic_load_acq(). > >> The atomic_store() functions always have release semantics. > > So while atomic_load() is used in an example in the man page, > there is no prototype for atomic_load/atomic_store, nor is there > an implementation. You are saying that the ONLY form is atomic_store_rel > instead of atomic_store (which doesn't exist). I think the man page > could use some minor clarification. Yes, it probably could. :) I'll see what I can come up with for that. > My point about the acquire/release "bugs" is that incorrect code > will work on IA32 because of the stricter memory ordering guarantees. > Getting every use correct is non-trivial, especially if there are a > lot of them, or if other code changes around the atomic op. It is > certainly easiest to program if all atomic ops have acquire/release > semantics, but non-optimally-performing on IA64. So I guess that > is one more thing against the use of atomic operations. One way to keep them more sane is to not use atomic ops all that much. Right now they are used in very few places. > 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. > At least the ia64 atomic code does "the right thing" with acquire/release > semantics on load/store. > > Kevin -- John Baldwin <jhb@FreeBSD.org> -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010103084423.jhb>