Date: Tue, 02 Jan 2001 11:36:19 -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.010102113619.jhb@FreeBSD.org> In-Reply-To: <200101020510.WAA13199@fast.cs.utah.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On 02-Jan-01 Kevin Van Maren wrote: > I didn't see the Jason Evans flame thread on -arch. Does > anyone have a pointer to it in the mail archive? > > In the interim, I think atomic_{increment,decrement}, even if > they are just syntactic sugar to atomic_{add,subtract}, should be > provided. After all, we use "++" as syntactic sugar to "+=1". > [The fact that gcc uses an intermediate register to add an immediate > constant is bogus, and not sufficient reason by itself to use > atomic_increment.] On x86 the code is slightly better for "++" > ver "+=1", while it really is just syntactic sugar on other systems. There is also a desire to try and keep the atomic API from being too huge I think. Atomic operations are _expensive_. One thing you are forgetting about on the x86 is that an atomic op on an SMP system requires a 'lock' prefix. The cost of locking the bus drowns out the savings you may get by getting one or two less instructions. > However, I also have another thought. Often times I need to > modify a value and also (atomically) determine it's (old|new) > value. Primitives that use "xadd" instead of "add" or "sub" > provide atomicity and eliminate an extra read. Yes, trashing > the added value may cause a register to spill if the value is > needed again later, but often times it is never used again anyway. > [pre-processor can negate the "sub"; worst case we need an extra > "neg" instruction for atomic_subtract, but the subtraction will > still be atomic.] Essentially, the (old) value is available for > free, so why not provide it? It might even make sense to always > provide the old value for add/subtract, and have gcc throw away > the unused output (unless the input value is reused, when we'd > lose a whole register to the xadd). This might very well be a good idea to do. Having each of the atomic ops that currently return void return the new value (probably easiest to do that). The ia64 has a 'fetchadd' instruction for example. > Even if the processor does not support xadd-like operations, it > can be emulated (more expensively) using load, add, cmpxchg, loop- > if-failed [similar to the code frag below, but with a while() loop.] > But by providing a primitive, it can be optimized much further > than just C code using an atomic cmpxchg operation (and is > "negative cost" on x86 -- faster than the non-atomic version). Yes, an atomic_cmpset() loop is how the atomic ops are performed on the ia64. > In Julian's acquire_writer, we need to do an atomic compare-and-swap > operation, instead of assuming two operations are atomic (because the > above acquire_reader code could be executed between the two following > statements): > > => if ((ngq->q_flags & (~SINGLE_THREAD_ONLY)) == 0) { > => atomic_add_long(&ngq->q_flags, WRITER_ACTIVE); > > Here is a possible code sequence to "just get it working" (at least > I *think* this fixes the alleged problem): > [ register int flags; ] > => flags = ngq->q_flags; > => if ((flags & (~SINGLE_THREAD_ONLY) == 0) && > => atomic_cmpset(&ngq->q_flags, flags, flags + WRITER_ACTIVE)) { Yes, this does look correct. > 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.) > 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.010102113619.jhb>