What I mean is - the whole point of the LOCKed instruction is usually to say "I own this data now". If you defer it and allow updates to proceed, then... you just broke the code!
More simply put, I can atomically MOV [BYTE PTR eax],IMM without LOCK but I cant atomically set bits that way. I see no fundamental reason why, if the CPU supports the former, it can’t economically support the later.
-
-
You could probably build special hardware to pipeline atomics to specific memory locations, but generally you have to read/write an entire cache line at a time, so that piece of memory has to be locked while you do that
-
Please bear with me on this: There's currently a piece of hardware that can atomically write just 1 byte into a 64-byte cache line. So clearly it's transforming (old cache line, write request) -> (new cache line). QUESTION: What is this hardware, and can it not support a ROP?
- 3 more replies
New conversation -
-
-
The fundamental scariness is the memory ordering model and handling exceptions and all that stuff. There's genuine dragons there. And if you loosen the model you get different dragons (see Alpha, Itanium, etc).
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.