What is an example program that has a bug due to _ReadBarrier() not being called?
The MSDN article on _ReadBarrier():
http://msdn.microsoft.com/en-us/library/z055s48f(v=vs.120).aspx
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.
This post, by my favorite blogger, will explain everything you ever had about read and write barriers: Barrier (and in a very humorous and tongue-in-cheek manner, too)
The article is rather long and starts with the basics of synchronization (mutexes) and then goes deeper and deeper into the different lighter-weight synchronization methods and discusses barriers at length. There are sample programs every step of the way, including the odd behavior they have (and the difficulty in getting this behavior to manifest on modern machines due to the behavior of the CPU).
BTW, (to reference Hans’ comment) It’s not that only Itaniums experience synchronization bugs, it’s that Itaniums are designed to take full advantage of complete reordering and parallelization, under the assumption that the dev/compiler knows what he/she/it is doing and will have used barriers in all the right places. Other platforms like x86 guarantee that certain instructions will be executed in-order, while other platforms like x86_64 don’t guarantee the ordering of other instructions but will, in practice and mostly for sanity and compatibility reasons, execute them (usually) in-order (see the linked blog post).