System information
* CPU: 11th Gen Intel Core i7-1165G7
* System: Linux Mint 22.2
* Kernel: 6.11.0-1014-lowlatency (no ntsync)
* Sys libc: GNU C library 2.39
* Wine: 9.0
* Compiler: GCC 13 (both)
Configurations and time of execution (lower is better)
* linux std: ( 8.150 s) std::mutex, backed by pthread
* linux boost: (10.936 s) boost::mutex
* win std: (20.246 s) std::mutex, backed by CRITICAL_SECTION
* win boost: ( 4.849 s) boost::mutex
* win srw: (15.853 s) SRWLOCK
* win mcf0i: ( 4.117 s) _MCF_mutex from mcfgthread, inlining disabled
The test uses code from https://github.com/markwaterman/MutexShootout
Hyperfine screenshot: https://files.lhmouse.com/20250826-155709.png
When boost::mutex is compiled natively it's slower than glibc, but when it's compiled for Windows and run in Wine it outperforms everything except mcfgthread, including native glibc mutex. Does this mean the glibc mutex is inferior in design, or is it sorta magic in thread scheduling in Wine that makes boost::mutex behave better in this test?
Two things immediately come to mind:
1) caching. Since Wine is an emulator it is an abstraction layer not present in your other scenario. It could be possible Wine is intelligently storing instructions. This would have massive benefits in the case of string interpolation where parsing a string is expensive and if the result of a parsed string is stored in memory then the extra layer with Wine should be dramatically faster.
2) hardware contexts. If one scenario is more CPU heavy than memory heavy and the other scenario the opposite you will get unexpected results, because different things are happening. It might appear that these scenarios are executing similar instructions, but that may not actually be the case.