Spin Loop Hint support: Draft JEP proposal (original) (raw)

Andrew Haley aph at redhat.com
Wed Oct 7 08:14:25 UTC 2015

On 05/10/15 21:43, Gil Tene wrote:

I see SpinLoopHint as very separate from things like MONITOR/WAIT (on x86) and WFE/SEV (on ARM), as well as any other "wait in a nice way until this state changes" instructions that other architectures may have or add.

Mechanisms like MONITOR/WAIT and WFE/SEV provide a way to potentially wait for specific state changes to occur. As such, they can be used to implement a specific form of a spin loop (the most common one, probably). But they do not provide for generic spinning forms. E.g. loops that have multiple exit conditions in different memory locations, loops that wait on internal state changes that are no affected by other CPUs (like "spin only this many times before giving up" or "spin for this much time"), and loops that may use transactional state changes (e.g. LOCK XADD, or wider things with TSX) are probably "hard" to model with these instructions.

Yes, you're right: there's no real way to combine these things, and support for WFE requires some other kind of interface -- if I ever manage to think of a nice way to express it in Java. So, my apologies for hijacking this thread, but now you've got me thinking.

In an ideal world there would be a timer associated with WFE which would trigger after a short while and allow a thread to be descheduled. However, it is possible to set a periodic timer which regularly signals each worker thread, giving it the opportunity to block if unused for a long time. This should make a much more responsive thread pool, so that when worker threads are active they respond in nanoseconds rather than microseconds.

[ An aside: WFE is available in user mode, and according to Intel's documentation it should be possible to configre an OS to use MONITOR/WAIT in user mode too. I don't know why it doesn't work. ]

Andrew.

More information about the core-libs-dev mailing list