Hacker News Reader

Comment by superdisk | Hacker News Reader

Sleep, at least on Windows, is allowed to have +/- 15 ms (default system heartbeat interval) of accuracy, which I don't think would work for this case.

https://docs.microsoft.com/en-us/windows/desktop/api/synchap...

I could mess around with the Win32 API or the NT API or something to make the heartbeat rate more granular, but according to the docs that kills battery, so I'm guessing it's going to be doing pretty much the same thing as what I'm doing manually.

View on HN

... that can still work. Measure how much time it actually slept and adjust accordingly. Or, is there some timer that runs at a reasonable rate (100Hz) where you csn yield once you've done 10msec worth of emulation? (I don't know the windows API, so just spitballing from the embedded world here)

You seem like you appreciate good timers. If you ever want to revolt in horror/have a few hearty belly laughs, look into how windows has and does handle various granularities of timing

Yep, we had this exact issue on our live servers deployed to Windows Server 2016 in a VM - essentially I would do:

1) post tasks to process some data

2) while(tasksNotFinished) Sleep(1);

Well, very quickly found out that the Sleep(1) was always a minimum of 16ms(or a multiple of 16ms), which made the whole thing stupidly slow. We fixed it by running timeBeginPeriod(1) which overrides the system timer resolution to 1ms. Yes it would kill the battery on laptops, but on a server this is not an issue.

The way I would solve that is an event and a count of tasks. When the last thread to complete its job sees InterlockedDecrement(&ntasks) == 0, call SetEvent to wake up the waiting thread.

Yes, that was another solution we considered but we needed to deploy a patch quickly and setting the timer resolution was considered less risky and faster to do. But it would have worked as well as it should wake up the waiting thread immediately when used with WaitForMultipleObjectsEx.

Raising the timer interrupt to 1ms with timeBeginPeriod should still be less costly (with regards to power consumption) than a spin loop. But yeah it's all tradeoffs..

Yeah I am well aware. I faced issues that reminded me of this when doing some audio stuff. Including on Windows.

Reply on news.ycombinator.com