"Indirect", "pretty direct"... It's subjective.
(It is not an API documentation; it is an implementation specification.)
Yes, but unlike these, atomic_read returns a value.
Without me (the API user) providing extra barriers, that value may
become something else whenever someone touches code in the vicinity of
the atomic_read.
You are right, atomic_read is not only different from accessors that
don't retunr values, it is also different from all other accessors that
return values (because they all also modify the value). There is just
no actual API documentation, which contributes to the issue that some
people (or at least one: me) learn a little bit late how special
atomic_read is.
A lot of different though related issues are discussed in this thread,
but I personally am only occupied by one particular thing: What kind of
return values do I get from atomic_read.
Probably good advice, like generally if driver guys consider lockless
algorithms.
OK, that's what I slowly realized during this discussion, and I
appreciate the explanations that were given here.
I could, or could not, if I were through with auditing the code. I
remembered one case and posted it (nodemgr_host_thread) which was safe
because msleep_interruptible provided the necessary barrier there, and
this implicit barrier is not in danger to be removed by future patches.
--
Stefan Richter
-=====-=-=== =--- =---=
http://arcgraph.de/sr/
-
