Reinstate "Fix inaccurate ticks in windows port"

[bknicholls]

Reinstate "Fix inaccurate ticks in windows port"

Description

Reinstates PR #142 by that was reverted in #143 by . The reason given for the reversion was "Backing this out to merge it after the next Kernel release" which was in August 2020.

Test Steps

When running the Windows port with configTICK_RATE_HZ 1000 the program runs at roughly half real time speed.
Tested on Windows 11 24H2 on a 11th Gen Intel(R) Core(TM) i7-11850H @ 2.50GHz.

Checklist:

• [x ] I have tested my changes. No regression in existing tests.
• I have modified and/or added unit-tests to cover the code changes in this Pull Request.

Related Issue

#143 and #143

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[cobusve]

I remember the last time we tried this some of the "Full Demo" tests that we run on the Windows Simulator to confirm FreeRTOS is behaving correctly were failing due to the tests depending on the incorrect timing in the Windows Simulator.

We should confirm that when all of the "Full Demo" is enabled at the same time the tests are still passing after this update.

[bknicholls]

Sorry I'm a bit new at this and I don't know what full demo tests you're referring to. Are you referring to the two Win32 demo projects in base FreeRTOS repo? What do you need me to do on my end to verify the tests?

[aggarg]

Are you referring to the two Win32 demo projects in base FreeRTOS repo? What do you need me to do on my end to verify the tests?

Yes, @cobusve means those demos only. We want to run time for a while and ensure that those are not failing.

[rawalexe]

hello @bknicholls ,
Just following up if you had time to update your branch and test the demo

[bknicholls]

Hi @rawalexe

Sorry I was getting smashed with work before Christmas and then had a couple of weeks off.

I've spent today testing and I do get errors from the demos with my changes, but I also get errors running off main so I don't believe there has been a regression.

I'm able to consistently replicate it by putting my computer under load. Compiling my project in VSCode with cmake clean/rebuild is enough to trigger the errors in both the MinGW and MSVC implementations.

As a sanity test I ran the posix demo in WSL and did the same test with clean/rebuild and it didn't have a problem so it's definitely Windows specific.

I've tried a heap of different things today to see if I can solve the problem but no luck so far.

It's late so I'll have another look tomorrow with a fresh brain.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[bknicholls]

I've done extensive testing on my computer including running main and my change overnight while idle and putting the system under load and eventually the demo will start outputting errors. When idle I've only seen it last maybe half an hour give or take before it starts outputting errors. Depending on the load it can be immediate.

I tried CreateWaitableTimerEx with the high resolution option, using multimedia timers with callbacks, using Multimedia Class Scheduler Service to give the timer and/or interrupt and/or task threads priority, using critical sections instead of mutexes, adding logging to see the tick skips and deviations and latency to the fake interrupt tick processing and I can't find an option that performs more reliably than main or CreateWaitableTimer, but at least with CreateWaitableTimer the emulator performs better with the tick rate roughly following wall clock time.