bcraig added a comment. In https://reviews.llvm.org/D37677#866743, @Quuxplusone wrote:
> This current patch just swaps out std::mutex for a std::mutex-alike class > that claims to be faster for uncontested accesses. Definitely safer than my > interpretation. :) If this patch actually helps, then I would offer that the > class could be provided as a reusable class `std::__spin_lock` in the <mutex> > header instead of being hidden inside `__assoc_shared_state`. I think the bar for accepting this should be significantly faster, and not just a little faster. Spinlocks don't behave as well as mutexes in abnormal conditions. Spinlocks are more likely to cause priority inversion. They are more likely to cause throughput issues when there is a lot of contention, as the spinlock'd thread will consume a full time slice before relinquishing a cpu. On Windows, CRITICAL_SECTION and SRWLOCK become electrified <https://blogs.msdn.microsoft.com/oldnewthing/20111007-00/?p=9443> during process termination to avoid indefinite hangs. We shouldn't give all of that up for a minor perf gain. We might give it up for a large perf gain though. https://reviews.llvm.org/D37677 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
