Messages in this thread | | | Date | Fri, 11 Feb 2005 01:27:36 -0300 | From | Werner Almesberger <> | Subject | Re: [PATCH] arp_queue: serializing unlink + kfree_skb |
| |
David S. Miller wrote: > Absolutely, I agree. My fingers even itched as I typed those lines > in. I didn't change the wording because I couldn't come up with > anything better.
How about something like:
Unlike the above routines, atomic_???_return are required to perform memory barriers [...]
I think "implicit" and "explicit" here are just confusing, because you don't define them, and there's no intuitively correct meaning either.
Perhaps a little warning could also be useful for the reader who wasn't paying close attention to whose role is described:
Note: this means that a caller of atomic_add, etc., who needs a memory barrier before or after that call has to code the memory barrier explicitly, whereas a caller of atomic_???_return can rely on said functions to provide the barrier without further ado. For the implementor of the atomic functions, the roles are reversed.
> You still get the memory barrier, whether you read the return > value or not.
That might be something worth mentioning. Not that a construct is used that gcc can optimize away when nobody cares about the return value.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |