Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I have read somewhere that hyperthreading can make 32-bit int (on a 32-bit processor) read and write non-atomic even when it is boundary aligned. Can anyone explain how hyperthreading effects this?
If that were true, it would be some kind of horrible CPU bug that would be specific to one particular model or stepping. That 32-bit reads and writes are atomic is fundamental to the properties of the x86 platform and is relied on by Windows, Linux, and lots and lots of application software.
The only thing I can think of that this might have been referring to is transitioning from single-core CPUs without hyper-threading to single-physical-core CPUs with hyper-threading. On a single-core x86 CPU without hyper-threading, single instructions (such as increment) that do read-modify-write operations on aligned 32-bit variables are atomic even without a lock prefix. (They are not guaranteed to be, they just happen to be.) A CPU with hyper-threading behaves a lot like a CPU with two physical cores, so read-modify-write operations (other then exchange) are not guaranteed atomic without a lock prefix.
It’s an irrelevant distinction now since the vast majority of CPUs your software will encounter will have more than one core one way or another. So even single-instruction read-modify-write operations on aligned 32-bit values will not be atomic unless locked. (Exchange being the exception, since it’s locked even without the prefix.)