David S. Miller wrote:
This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter and bitops operations
properly.
Finally, some light is shed into one of the most arcane areas of
the kernel ;-) Thanks !
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. Who does them, the atomic_* function, or the user ?
In fact, I would call them "implicit", because they're hidden in the
atomic_foo functions :-)
void smb_mb__before_atomic_dec(void);
void smb_mb__after_atomic_dec(void);
void smb_mb__before_atomic_inc(void);
void smb_mb__after_atomic_dec(void);
s/smb_/smp/ :-)
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 ?
With the memory barrier semantics required of the atomic_t
operations which return values, the above sequence of memory
visibility can never happen.
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);
instead of
smp_mb__before_atomic_inc();
atomic_inc(foo);
smp_mb__after_atomic_dec();
? If yes, is this a good idea ?
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.
- Werner
--
_________________________________________________________________________
/ Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net /
/_http://www.almesberger.net/____________________________________________/
On Thu, Feb 10, 2005 at 01:23:04AM -0300, Werner Almesberger wrote:
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);
instead of
smp_mb__before_atomic_inc();
atomic_inc(foo);
smp_mb__after_atomic_dec();
Yes you can.
? If yes, is this a good idea ?
Dave mentioned that on sparc64, atomic_inc_and_test is much more
expensive than the second variant.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} [off-list ref]
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Thu, 10 Feb 2005 15:56:47 +1100
Herbert Xu [off-list ref] wrote:
quoted
? If yes, is this a good idea ?
Dave mentioned that on sparc64, atomic_inc_and_test is much more
expensive than the second variant.
Actually, besides the memory barriers themselves, all variants
are equally expensive.
On old i386 chips, the test variants are indeed more expensive.
Linus told me this and there is a note about this in the
atomic_ops.txt file if you look at the current copy :-)
On Thu, 10 Feb 2005 01:23:04 -0300
Werner Almesberger [off-list ref] wrote:
David S. Miller wrote:
quoted
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.
quoted
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.
On Thursday 10 February 2005 22:50, David S. Miller wrote:
quoted
quoted
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.
What about the following:
Unlike the routines above, these functions should always perform memory
barriers before and after the operation in question so that all memory
accesses before and after the atomic operation are strongly ordered with
respect to the atomic operation itself.
--
Dmitry