On Thu, 10 Feb 2005 01:23:04 -0300 Werner Almesberger <[EMAIL PROTECTED]> wrote:
> David S. Miller wrote: > > Unlike the above routines, it is required that explicit memory > > barriers are performed before and after the operation. It must > > be done such that all memory operations before and after the > > atomic operation calls are strongly ordered with respect to the > > atomic operation itself. > > Hmm, given that this description will not only be read by implementers > of atomic functions, but also by users, the "explicit memory barriers" > may be confusing. 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. > In fact, I would call them "implicit", because they're hidden in the > atomic_foo functions :-) That's confusing to the implementer :-) > s/smb_/smp/ :-) Good catch, fixed in my local copy. > Do they also work for atomic_add and atomic_sub, or do we have to > fall back to smb_mb or atomic_add_return (see below) there ? Macros for the other routines don't exist simply because nobody ever had a use for them. In practice they will just work. > What happens if the operation could return a value, but the user > ignores it ? E.g. if I don't like smp_mb__*, could I just use > > atomic_inc_and_test(foo); You still get the memory barrier, whether you read the return value or not. > > These routines, like the atomic_t counter operations returning > > values, require explicit memory barrier semantics around their > > execution. > > Very confusing: the barriers aren't around the routines (that > is something the user would be doing), but around whatever does > the atomic stuff inside them. Yeah, it's the whole implicit/explicit wording issue discussed above. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
