Date: Tue, 02 Jan 2001 17:09:39 -0800 (PST) From: John Baldwin <jhb@FreeBSD.org> To: Kevin Van Maren <vanmaren@fast.cs.utah.edu> Cc: smp@FreeBSD.org, cp@bsdi.com Subject: Re: atomic increment? Message-ID: <XFMail.010102170939.jhb@FreeBSD.org> In-Reply-To: <200101022143.OAA08265@fast.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02-Jan-01 Kevin Van Maren wrote: >> > One more thought on atomic operations: If we don't assume assignments >> > are atomic, and always use atomic_load and atomic_store, then we a) can >> > easily provide atomic 64-bit operations on x86 (quick hack would be >> > to use a single mutex for all 64-bit operations), and b) we can port >> > to platforms where atomic_add requires a mutex to protect the atomic_add >> > or atomic_cmpset sequence. [Slow as molasses] On x86, the load/store >> > macros are NOPs, but the use also (c) makes it clear that we are >> > manipulating a variable we perform atomic operations on. >> >> 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.) > > The macros do (aligned) atomic assignments properly, but without the > acquire and release semantics provided by LOCK: it is currently > incorrect to release a lock by doing an "atomic_store(&lock, 0)". > For that to be allowed, they would have to use x LOCKed xchg or > something, as you say. You can't do an atomic_store(&foo), you have to use atomic_store_rel(&foo), which is what I tried to say in the manpage. I guess that didn't come across clearly. > From "man 9 atomic": > The first form just performs the operation without any explicit barriers. > The second form uses a read memory barrier, and the final variant uses a > write memory barrier. The store and load don't have all of the forms. The load just has the acquire form, and the store just has the release form. > I think separate memory barrier operations might also make sense. > On IA64, we have the "mf" and "mf.a" operation; on IA32, we > can emulate it by "lock; addl $0,0(%esp)" for SMP, and a NOP for > uniprocessors (which is as free as you can make it, since (%esp) > had better be exclusivly owned by the CPU). Memory barrier ops > could be used under the "enhanced" load/store primitives, but > they would be slower than direct encoded versions. > > I wonder how many problems we're going to have going from x86, where > all LOCKed atomic operations have acquire and release semantics, to > IA64, where they must be explicitly encoded. I guess it depends on > how many places we use atomic primitives. Things that use atomic operations and depend on ordering should already be using the 'acq' and 'rel' variants of the atomic operations. See the mutex micro-operations for example that use atomic_cmpset_acq_ptr() and atomic_store_rel_ptr(). > 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.010102170939.jhb>