5 ms·

Agree. Let's document this trick and I'm happy with that unfair scheduling inconvenience for CPU heavy operations.

• deleted 4y ago
  [deleted]
• topspin 4y ago
  Seconded. Although I think Thread::yield should do what it says on the tin in the case of lightweight threads and it's hard to understand why they chose to not make it so, I don't care much. If the only problem I have to anticipate to get the full benefit of a well behaved lightweight threat scheduling is strategically sprinkling yield points inside those few tight loops that might actually threaten to hog a core then it's a net win.
  • anonymousDan 4y ago
    Having to do it manually is tedious and error prone IMHO. Better to have a reasonably good automated mechanism that you can disable if you wish).
    • topspin 4y ago
      > tedious and error prone IMHO It's neither. The frequency of non-blocking CPU bound sections of most applications is low and so the need to introduce scheduling hints is also infrequent. Aside from an endless, non-blocking loop that never yields omitting possibly beneficial yield points isn't an error; scheduling will not be ideal but the process will ultimately produce the same result.
  • topspin 4y ago
    Thinking about this further, a pragmatic enhancement to Thread::yield might look like this: enum Hint { ALWAYS, FREQUENT, SOMETIMES, INFREQUENT, NEVER } Thread::yield(Hint); The method could be intrinsic to the compiler+runtime to provide runtime optimization (loop unrolling, tuning, etc.) of the 2nd - 4th cases. This would neatly avoid the need to: long n = 0; while (true) { // stuff if (++n > SOME_LIMIT) { n = 0; // yield here } } ... or similar.