On Thu, 10 Feb 2005 01:23:04 -0300
Werner Almesberger <wa@xxxxxxxxxxxxxxx> 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.
|