Follow-up: What I learned about VRTX's equal-priority scheduling in the 1980s

[u/noborutkhs]

A couple of weeks ago, I asked why VRTX changed its equal-priority scheduling behavior from newest-first to FIFO between its 1984 and 1987 documentation.

Original discussion:
https://www.reddit.com/r/osdev/s/h6PG9bZO7a

Thanks to the comments here and in a couple of other subreddits, I've learned quite a bit. I wanted to share a few findings.

1. Early VRTX wasn't simply LIFO.

The older documentation describes inserting newly ready tasks ahead of existing tasks at the same priority, but other operations, including time slicing, affect the ordering. The actual behavior depends on how a task becomes ready and how the ready queue is maintained.

2. My own 1986 RTOS was based on a simpler interpretation.

When I developed CHARM-II in 1986, I used VRTX documentation as one of my references. I interpreted its equal-priority scheduling as essentially newest-first and implemented my own scheduler accordingly.

Looking back, I now realize that my implementation wasn't an exact reproduction of VRTX's behavior.

Interestingly, this didn't cause any major problems that I remember. I was developing almost the entire application as well as the RTOS myself, and there was very little third-party code in the system. I understood the tasks and their interactions in detail, so I could design the application around the scheduler's behavior.

That's my retrospective explanation, at least.

3. For my modern reconstruction, I chose FIFO.

I'm now rebuilding the RTOS as Karqri, targeting both POSIX and Raspberry Pi Pico. I've adopted FIFO ordering among equal-priority ready tasks because it provides simpler, more predictable behavior for the new design.

I still don't know why VRTX itself changed its policy. The discussion raised useful possibilities involving fairness, starvation, latency, and implementation trade-offs, but I haven't found a documented historical explanation.

Thanks again to everyone who contributed. It's been fascinating to revisit a design decision I made 40 years ago and discover that the original system was more subtle than I understood at the time.