Message319482
| 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:36 | ethan smith | set | recipients:
+ 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:35 | ethan smith | set | messageid: <1528914515.82.0.947875510639.issue30747@psf.upfronthosting.co.za> |
| 2018年06月13日 18:28:35 | ethan smith | link | issue30747 messages |
| 2018年06月13日 18:28:35 | ethan smith | create |
|