WordLock doesn't need per-thread data
Created attachment 339092 [details] Patch
Benchmark results look neutral to me: ~/OpenSource> ./LockSpeedTest-baseline wordlock 1 4 1 0 40 2 WTFWordLock: 40014.319 KHz WTFWordLock = {40014.319}; ===== ~/OpenSource> ./LockSpeedTest wordlock 1 4 1 0 40 2 WTFWordLock: 41667.624 KHz WTFWordLock = {41667.624}; ===== ~/OpenSource> ./LockSpeedTest-baseline wordlock 1 4 10 20 40 2 WTFWordLock: 15257.590 KHz WTFWordLock = {15257.590}; ===== ~/OpenSource> ./LockSpeedTest wordlock 1 4 10 20 40 2 WTFWordLock: 15336.106 KHz WTFWordLock = {15336.106}; ===== ~/OpenSource> ./LockSpeedTest-baseline wordlock 1 4 128 1024 40 2 WTFWordLock: 1505.244 KHz WTFWordLock = {1505.244}; ===== ~/OpenSource> ./LockSpeedTest wordlock 1 4 128 1024 40 2 WTFWordLock: 1506.206 KHz WTFWordLock = {1506.206};
Comment on attachment 339092 [details] Patch r=me if it does not cause perf regression. I think it should be perf-neutral since basically constructing ThreadData is cheap. I think we can use this approach in ParkingLot to remove ThreadSpecific.
Comment on attachment 339092 [details] Patch Clearing flags on attachment: 339092 Committed r231151: <https://trac.webkit.org/changeset/231151>
All reviewed patches have been landed. Closing bug.
<rdar://problem/39825097>
> I think we can use this approach in ParkingLot to remove ThreadSpecific. That would be cool!