Messages in this thread | | | Date | Sat, 18 Dec 2004 15:47:56 -0500 | From | Brian Gerst <> | Subject | Re: What does atomic_read actually do? |
| |
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. > The C standard has nothing to say about atomicity w.r.t. multithreading or > multiprocessing. Is this a gcc compiler thing? If so, does gcc guarantee > that it will fetch aligned ints with a single instruction on all platforms > or just x86? And what's with volatile since if the C standard implies > nothing about multithreading then it follows that volatile has no meaning > with respect to multithreading either? Also a gcc thing? Are volatile > semantics well defined enough that you can use it to make the compiler > synchronize memory state as far as it is concerned? > > Joe Seigh
For x86, the processor guarantees atomicity for simple aligned reads or writes. Read-modify-write instructions need a lock prefix in order to become atomic. The volatile is there so gcc doesn't miss the value changing from within an interrupt.
-- Brian Gerst - 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/
| |