3 ms·
Fair enough; I had used it mostly because I wanted to ensure fairness conditions on some locked code. That's interesting, I'll rewrite the tests with vanilla t
by tombert 2y ago
Fair enough; I had used it mostly because I wanted to ensure fairness conditions on some locked code.
That's interesting, I'll rewrite the tests with vanilla threads and update the page!
ETA:
Ok, I updated the tests to use vanilla platform threads, and surprisingly ReentrantLock is still faster. Here are the results:
Total time for synchronized: 202ms, counter: 2000000
Total time for atomic: 27ms, counter: 2000000
Total time for lock: 58ms, counter: 2000000
- charleslmunger 2y agoDid you use fair scheduling with ReentrantLock? That could account for a difference of intrinsic locks (synchronized) was a fair lock. This type of benchmark is a pathological because the optimal scheduling policy is for one thread to starve all the others until it finishes, which is basically never what you'd want in a real project.
- tombert 2y agoI tried both fair and the default, it didn’t make a significant difference. People have pointed out that I should probably be using something like JMH instead of basic timers. I plan on writing an update to this with those numbers.
- invalidname 2y agoAFAIK synchronized isn't a fair lock but according to the spec it's implementation dependent. The numbers are bad because OP is using manual benchmarking and falling for the microbenchmarking traps with JIT optimizations. There's no warmup or anything...