Messages in this thread | | | Date | Wed, 18 Jan 2012 16:50:49 +0000 | From | "Jan Beulich" <> | Subject | Re: [PATCH 2/2] ix86: atomic64 assembly improvements |
| |
>>> On 18.01.12 at 17:36, "H. Peter Anvin" <hpa@zytor.com> wrote: > On 01/18/2012 06:24 AM, Jan Beulich wrote: >> The cmpxchg8b variants of "set" and "xchg" are really identical, and >> hence don't need to be repeated: %ebx and %ecx don't need to be copied >> into %eax and %edx respectively (this is only necessary when desiring >> to only read the stored value), and the LOCK prefix should also be used >> in "set" (other than the comment that is now being removed was saying, >> there is - to my knowledge - no *architectural* guarantee that aligned >> 64-bit writes would always be carried out atomically). > > EWHAT? > > It's atomic in the same way a MOV is atomic.
Then please point me to where this is documented.
As I understand it, there is nothing keeping the CPU (or something down the bus) from executing the unlocked version as two 32-bit reads followed by two 32-bit writes.
> The CPU could, in fact, execute the locked version at all if the > unlocked version didn't behave like that.
Assuming you meant "could not", that's not true: As long as the external world has a way to know that both items are locked (think of the old bus lock mechanism when there were no caches yet), it can very well do so.
I do not question that in practice all CPUs behave as described, but without an architectural guarantee (and with the code in question not being used in hot paths afaik) I see no reason why it should depend on undefined behavior.
Jan
> Unless you have a specific instance where you think this might be > violated, please let me know. > > -hpa > > -- > H. Peter Anvin, Intel Open Source Technology Center > I work for Intel. I don't speak on their behalf.
| |