Provides a significant speedup to lock performance: 0m3.448s vs 0m47.917s for the 8 thread counting test below.

Unfortunately seems to fail for a few things currently, https://codereview.chromium.org/2887263002 and notes below suggest it may not work for condition variables. ISTR many of the failures being in places the Fuschia team has spent some time deflaking recently, so some may have been real issues. Will resubmit that CL and post test failures here.

Original internal discussion:

Simple test which uses 8 threads to increment a counter 1000000 times (clang -O2 -lpthread)

Linux (Z620): $ time thread-test
Sum 8000000

real	0m1.012s
user	0m1.404s
sys	0m6.004s

macOS (2012 Pro): $ time thread-test
Sum 8000000

real    0m47.917s
user    0m3.477s
sys     0m46.397s

I'm wondering if the issue is even further exacerbated on Mac Pro devices with higher core counts...

I know Apple wrote this some time ago:

https://webkit.org/blog/6161/locking-in-webkit/

I seem to recall private discussions centering around us being unable to reproduce this; though may be remembering incorrectly. I'm wondering if they wrote that since they all work on Mac Pros...

Also to offset any concerns that the number of cores in the Z620 help, the timing using taskset for limiting to four cores is faster on Linux:

$ time taskset 0x11 ./thread-test
Sum 8000000

real	0m0.803s
user	0m0.776s
sys	0m0.796s


Someone pointed out:

https://blog.mozilla.org/nfroyd/2017/03/29/on-mutex-performance-part-1/

Which suggests setting _PTHREAD_MUTEX_POLICY_FIRSTFIT, this does indeed speed the code up significantly:

$ time ./thread-test 
Sum 8000000

real	0m3.448s
user	0m1.204s
sys	0m25.009s

https://bugzilla.mozilla.org/show_bug.cgi?id=1353787

Suggests that this can't be used with ConditionVariables in a reliable manner.
 

Deleted: test.cc 645 bytes

test.cc 645 bytes View Download