On 10/05/2015 03:59 PM, Peter Levart wrote: > > On 10/05/2015 11:41 AM, Andrew Haley wrote: >> Hi Gil, >> >> On 04/10/15 17:22, Gil Tene wrote: >> >>> Summary >>> >>> Add an API that would allow Java code to hint that a spin loop is >>> being executed. >> >> I don't think this will work for ARM, which has a rather different >> spinlock mechanism. >> >> Instead of PAUSE, we wait on a lock word with WFE. WFE puts a core >> into a lightweight sleep state waiting on a particular address (the >> lock word) and a write to the lock word wakes it up. This is very >> useful and somewhat analogous to 86's MONITOR/MWAIT. >> >> I can't immediately see how to generalize your proposal to ARM, >> which is a shame. > > Just a thought... > > ARM WaitForEvent/SendEvent instructions sound like a kind of > park/unpark, but on a CPU-core-level (WFE) and global system-level > (SendEvent).
Pretty much, although the wakeup is just a store. > I wonder whether it would be possible to use them to optimize the > latency of the implementation of park/unpark. The same goes for Spin > Loop Hint. Would it be possible to incorporate spin-looping in the > park/unpark implementation for x86 itself? Higher-level > synchronization constructs (like locks, synchronizers, etc..) would > then just use park/unpark and not bother with spin-looping > themselves. I spent a while thinking about that, and I'm not sure it's possible. WFE can wait for a very long time, and there is a general presumption that if a thread blocks it really should be descheduled rather than hog a core with a WFE. WFE is excellent if you have many cores (more cores than threads) and don't mind dedicating them to particular tasks: it's great for fork/join thread pools, etc, because it doesn't have the overhead of blocking and unblocking. Maybe the best thing would be a different version of park/unpark. Andrew.
