Hacker News Reader

Comment by test-account | Hacker News Reader

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

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.

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.

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).

> 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.

Reply on news.ycombinator.com