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.
