Simulator task scheduling with Windows simulator

Kernel
1

Hi,
Some background.
We use Windows simulator for servo control system testing.
Servo gets interrupts approximately every 31 uSec.
Windows cannot create events at such rate so we schedule (with counting semaphore) 32 events each tick.

implementation:
Freewheeling low priority task posts a counting semaphore 32 times to high priority task and then sleeps for 1 tick.
Expected: high priority tasks will do its job 32 times within one system tick, that’s, preemption of low priority task by high priority task will occur 32 times and should take small amount of time and finish fast (no significant work done)
In reality each preemption takes approximately 1 tick.

Other observation:
If I swap priority and post 32 times a semaphore from low priority task to high priority task, it works as expected. But this is not exactly what i need.

Any thoughts ?

Best regards
Rasty

2

Windows is always going to be tricky as its not real time. What is your tick period (frequency)? If you post from a low priority task to a high priority task then the high priority task will probably process each semaphore post in turn as it will unblock each time the semaphore gets posted.

3

System tick is 1 mSec. I measured this with real-time clock. 1000 +/- 1 increments per second.
The idea is to trigger a task-switch each event, exactly as it would be in real system, where we schedule task from interrupt.
That’s why I choose to post a semaphore from low priority task to high priority, which looks unusual . It appears that every context switch takes apx 1 tick, which is too much taking into account Core i7. It sounds like task switch has some “granularity”, maybe at system tick boundary.

4

The Windows port only simulates the tick using a very high priority background task - it cannot actually generate and interrupt in Windows for real.

5

I understand. Sleep of 1 tick, produces a delay about 1 mSec. I do not expect “real time” here.
The point is that a context switch from low priority task to high priority task and back as result of posting of a counting semaphore takes much longer than expected while context switch duration somehow correlates with system tick rate, which is unexpected in that case. I’d expect that context switch will take a couple of microseconds while it takes 1 system tick or sometimes two.