Re: What does atomic_read actually do?

[Brian Gerst]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/