3 ms·
I think the busy loop version can use Thread.onSpinWait() to improve performance if the tryLock fails. [1] https://docs.oracle.com/en/java/javase/17/docs/api/j
by _old_dude_ 5y ago
I think the busy loop version can use Thread.onSpinWait() to improve performance if the tryLock fails.
[1] https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/Thread.html#onSpinWait https://docs.oracle.com/en/java/javase/17/docs/api/java.base...()
- charleslmunger 5y agoIndeed, although userspace spinlocks are almost always a bad idea, it's possible to write a much better one than repurposing ReadWriteLock. 1. As you say, use onSpinWait 2. It emits a load barrier on each failed trylock call, from the underlying strong integer CAS. Ideally it would use a cas with relaxed memory order, and use an acquire fence only if successful. 3. The read path emits store barriers on release, which is unnecessary. Releasing could use a relaxed order fetch-add instruction. It's theoretically possible that the JIT would be smart enough to optimize these with the existing code, but that's asking a lot from its analysis, including that the thread local storage writes for detecting reentrance aren't "real" writes that need to be made visible to other threads.