Messages in this thread | | | From | "Joseph Seigh" <> | Subject | Re: What does atomic_read actually do? | Date | Sat, 18 Dec 2004 14:20:44 -0500 |
| |
On Sat, 18 Dec 2004 19:34:27 +0100, Arjan van de Ven <arjan@infradead.org> wrote:
> On Sat, 2004-12-18 at 11:23 -0500, Joseph Seigh wrote: >> It doesn't do anything that would actually guarantee that the fetch from >> memory would be atomic as far as I can see, at least in the x86 version. > > define atomic.... > > what linux atomics guarantee you is that you either "see" the old or the > new value if you use atomic_* as the sole accessor API, with the > footnote that this only holds if you don't forcefully misalign the > atomic_t. > > if you want ordering guarantees on top... you need to use explicit > bariers for that (wmb/rmb and friends). > > For the "no inbetween" rule, doing the read the way x86 does works on > x86, since x86 makes sure that on the write side, no intermediate > results become visible.
I mean atomic in the either old or new sense. I'm wondering what guarantees the atomicity. Not the C standard. I can see the gcc compiler uses a MOV instruction to load the atomic_t from memory which is guaranteed atomic by the architecture if aligned properly. But gcc does that for any old int as far as I can see, so why use atomic_read?
Joe Seigh
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |