Messages in this thread | | | From | Marco Elver <> | Date | Fri, 10 Jun 2022 18:32:36 +0200 | Subject | Re: [PATCH v2 2/6] bitops: always define asm-generic non-atomic bitops |
| |
On Fri, 10 Jun 2022 at 18:02, Luck, Tony <tony.luck@intel.com> wrote: > > > > +/** > > > + * generic_test_bit - Determine whether a bit is set > > > + * @nr: bit number to test > > > + * @addr: Address to start counting from > > > + */ > > > > Shouldn't we add in this or in separate patch a big NOTE to explain that this > > is actually atomic and must be kept as a such? > > "atomic" isn't really the right word. The volatile access makes sure that the > compiler does the test at the point that the source code asked, and doesn't > move it before/after other operations.
It's listed in Documentation/atomic_bitops.txt.
It is as "atomic" as READ_ONCE() or atomic_read() is. Though you are right that the "atomicity" of reading one bit is almost a given, because we can't really read half a bit. The main thing is that the compiler keeps it "atomic" and e.g. doesn't fuse the load with another or elide it completely, and then transforms the code in concurrency-unfriendly ways.
Like READ_ONCE() and friends, test_bit(), unlike non-atomic bitops, may also be used to dependency-order some subsequent marked (viz. atomic) operations.
> But there is no such thing as an atomic test_bit() operation: > > if (test_bit(5, addr)) { > /* some other CPU nukes bit 5 */ > > /* I know it was set when I looked, but now, could be anything */
The operation itself is atomic, because reading half a bit is impossible. Whether or not that bit is modified concurrently is a different problem.
Thanks, -- Marco
| |