This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ethan smith
Recipients Paxxi, Segev Finer, ethan smith, jyasskin, mark.dickinson, paul.moore, pitrou, serhiy.storchaka, steve.dower, tim.golden, vstinner, zach.ware
Date 2018-06-13.18:28:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1528914515.82.0.947875510639.issue30747@psf.upfronthosting.co.za>
In-reply-to
Content
When working on clang-cl support, I was advised here https://reviews.llvm.org/D47672#1131325 that we may be using hardware lock elision incorrectly. Copying from there:

> I also spoke to Andi Kleen here at Intel to make sure I got these inline assembly versions correct. And he's not sure CPython should be using these the way it is. It looks like they try to use the HLE versions anytime the memory order is acquire/release. But HLE isn't suitable for every acquire/release.

I believe if we just use the simple _InterlockedExchange/_InterlockedCompareExchange intrinsics, things should be safer.
History
Date User Action Args
2018-06-13 18:28:36ethan smithsetrecipients: + ethan smith, paul.moore, mark.dickinson, pitrou, vstinner, jyasskin, tim.golden, zach.ware, serhiy.storchaka, steve.dower, Segev Finer, Paxxi
2018-06-13 18:28:35ethan smithsetmessageid: <1528914515.82.0.947875510639.issue30747@psf.upfronthosting.co.za>
2018-06-13 18:28:35ethan smithlinkissue30747 messages
2018-06-13 18:28:35ethan smithcreate