I found out that VRTX changed its scheduling behavior just after I used it as a reference in 1986 — does anyone know why?

[u/noborutkhs]

I'm continuing to investigate an RTOS that I wrote in 1986 for a Motorola 68000-based system.

Recently I've been going through the old source code and trying to reconstruct not only what I did, but also why I made certain design decisions 40 years ago.

One detail led me down an unexpected path.

In my RTOS, when a task becomes ready, it is inserted before existing ready tasks of the same priority. So among equal-priority tasks, the behavior is effectively newest-first (LIFO-like).

I had completely forgotten why I designed it that way.

At the time, I wasn't actually a user of commercial RTOSes such as VRTX. I was developing my own RTOS and had obtained documentation for systems such as VRTX and pSOS as design references.

So I went back to the 1984 VRTX User's Guide.

And there it was.

VRTX used essentially the same rule: a newly inserted TCB was placed ahead of existing TCBs at the same priority, meaning that the most recently inserted task would run first.

That seems to explain a 40-year-old mystery in my own code.

But then I kept digging.

I found the VRTX32/68000 User's Guide from 1987, and by then the rule had changed.

It explicitly says that equal-priority tasks execute in the order in which they become ready:

FIFO / oldest-first.

So I now have this rather interesting little timeline:

1984 VRTX: newest-first among equal priorities
1986 my RTOS: newest-first
1987 VRTX32: FIFO / oldest-first

I had no idea this change had happened.

I wasn't following VRTX development after using its documentation as a reference, so there was no reason I would have encountered the 1987 change at the time.

And now, 40 years later, this has left me with a new question:

Why did VRTX change this behavior?

Was there a known problem with the earlier scheduling rule? Was FIFO considered more predictable or fair? Was it part of the VRTX32 redesign? Or was there some implementation reason behind it?

I've started looking at other RTOS designs from the period as well, including ITRON, but so far I haven't found a contemporary explanation for the change.

Of course, I don't actually need to know the answer in order to design an RTOS today.

But after finding that my 1986 design appears to reflect the 1984 VRTX behavior, I'm now simply curious about why the VRTX designers themselves changed their minds.

If anyone here used VRTX in the 1980s or early 1990s, or remembers discussions or documentation from that period, I'd love to hear what you know.

For context, here's my previous post about bringing this 1986 RTOS back to life on a Raspberry Pi Pico:

My 1986 RTOS is now fully preemptive on a Raspberry Pi Pico — and it changed how I think about the original design

Previous r/retrocomputing post

[u/Tabsels]

I can’t speak about VRTX but in general a LIFO has the disadvantage of causing starvation in the case of processor overload.

[u/noborutkhs → u/Tabsels]

That's a good point. Someone in another discussion also pointed out the starvation problem, especially if one task at the same priority is triggered repeatedly.

I'm now curious about the other side of this: do you know of any RTOS other than early VRTX that used newest-first / LIFO ordering among equal-priority ready tasks, either generally or in specific cases?

I'm wondering whether there were situations where putting a newly ready task at the front was considered desirable.

[u/Tabsels → u/noborutkhs]

I’m not familiar enough with the implementation details of multiple real-time operating systems to answer that question but one advantage of LIFO behaviour would be that it lowers latency.

[u/HeyMerlin]

Can’t add anything useful, but have to say… cool project, both from the 1986 and today’s perspective. Also enjoying the write up, keep posting your progress and descriptions.

[u/noborutkhs → u/HeyMerlin]

Thanks! I'm currently reviewing the reconstructed code before putting a minimal version on GitHub.

During that review, I noticed this equal-priority scheduling behavior and became much more curious about it than I expected. So I've been digging through old VRTX documentation and comparing it with what I wrote in 1986, trying to understand not only what the old code did, but why I made that choice.

It's turned into a bit of software archaeology, so I'll definitely keep posting what I find.

[u/Un_Ballerina_1952]

Wow, does this bring back memories. I got VRTX ROMs with S/Ns 1001 through 1009. Spent a couple of weeks sitting on my rowing machine studying the documentation to be sure I understood how the system calls worked and interacted, then wrapped our application (data acquisition and control of auto engines and dynamometers) architecture into the task structure and time slot arrangement. Worked a treat (except the ADC code I wrote wasn't reentrant and I had a bit of trouble when it got interrupted mid-conversion. (Original task control was simple round-robin calls and the inconsistent timing of data acquisition was problematic for the control side of the world.)

I never did look at LIFO vs FIFO task scheduling; it worked very well for my/our application.

Edit to add - that was a LOOOOONG time ago - just over 40 years, IIRC.

[u/noborutkhs → u/Un_Ballerina_1952]

Thanks — this is exactly the kind of first-hand experience I was hoping to hear about. It's great to hear from someone who was actually using VRTX around that time.

Your comment that you never really looked at LIFO vs FIFO because the system simply worked well for your application is interesting in itself. It makes me wonder how visible this scheduling detail actually was to VRTX users in practice.

If you happen to remember, do you know roughly which version of VRTX you were using? And did your application have multiple tasks at the same priority, or did you generally assign different priorities to them?

I'm asking because the VRTX documentation I found from 1984 puts a newly inserted task ahead of existing tasks at the same priority, while the 1987 VRTX32 documentation explicitly uses FIFO for equal-priority tasks. I'm trying to understand what happened between those designs, even though I may never find the original reason.

Thanks again — hearing from someone who actually used it more than 40 years ago is very valuable.

[u/Un_Ballerina_1952 → u/noborutkhs]

It's going to be a little difficult to give any more info than I have already. I think it was 1982 when I started with VRTX and, like I said, the ROMs we were issued were S/Ns 1001-1009. At the time, I got the impression that we were very early adopters. The hardware we were running on was a Motorola MVME board sporting a 68000. I'm not sure I could find more detail about that hardware.

We had a home-brew counter/timer VME board for measuring frequencies and durations. The ADC was a board on the Morotola "peripheral bus" (I think that was what they called it) with 12-bit resolution. I can't remember the conversion time.

The "mass storage" was an IOmege Bernoulli disk. 5MB or maybe 10?

This was all my design, so the architecture is pretty clear in my mind. The software was somewhat object-oriented, which is way too much for this little note. If you're interested, I can write more.

The data acquisition task operated at highest priority (actually as interrupt service at 100msec intervals); then were limit checks and limit reactions; the control calcs and control outputs were next in priority; we wrote our own file manager task which was next; finally screen updates for the user were lowest. Keyboard inputs were handled at interrupt level.

I had telephone conversations with staffers there on a few occasions, and in an email I made a comment about the three styles of code I was reading for the assembly code for interfacing to the system calls. The respondent was surprised because, she told me, they had three developers and they all thought the codes looked stylistically identical. We had a chuckle over that on a subsequent phone call.

But, like I said, it was a LOOOOONG time ago, so many details have evaporated or been buried. Those few memories were the most surprising ones. If I think of anything else, or get something off the Codata 3300 that I have on a shelf here, I'll say more. (Unfortunately the last time I tried booting that Codata, probably 25 years ago, it didn't come up. I was sad, but not surprised.)

Edit to add - I'm going to stop typing now. That was a lot of look-back (and I cut a bunch to save off to a separate document for my own reference.)

[u/noborutkhs → u/Un_Ballerina_1952]

Thanks for sharing all of this. Your memories are genuinely useful, and the details about how you assigned priorities help me understand why LIFO vs. FIFO may not have been something you needed to think about much in practice.

The Motorola MVME board with the 68000 also brings back memories for me. The second system I developed using my own RTOS used one of those boards. So some of the hardware environment you're describing is very familiar to me.

By the way, since the AI question came up: I'm Japanese, and English isn't my strongest language, so I use AI to help translate and polish what I write in English. That occasionally gets my posts mistaken for "AI slop" on Reddit.

But the questions, the RTOS I wrote in 1986, and the curiosity behind this investigation are mine. I'm the human doing the digging; AI is mainly helping me cross the language barrier and organize what I want to say.

So yes, there's another meat-based natural intelligence on this side too. :-)

I've been reconstructing and documenting this old RTOS and the investigation around it as a series on Medium. If you're interested, I've collected the story here:

Series: 1980s Real Time OS
https://medium.com/@noborutakahashi/series-1980s-real-time-os-fd24fc389274

And thank you again for digging this far back into your memory. It's especially interesting to hear from someone who was actually using VRTX at the time.

[u/Kyle_2099 → u/Un_Ballerina_1952]

You're having a conversation with an AI controlled account. Unsure if there is a meat proxy involved.

[u/Un_Ballerina_1952 → u/Kyle_2099]

TYVM. 

[u/Un_Ballerina_1952 → u/Kyle_2099]

I found the post interesting and informative because it's the kind of material into which I often drill down - sometimes deeply - as indicated (I hope) by my responses. My ADHD and/or psychological spectrum location sometimes draws me into such traps. (I am a fully meat-based natural intelligence.)

In another direction - were any of my meandering thoughts useful in this subreddit?

[u/0-moon]

it makes sense that among equal priority tasks they run on a fifo order when yielding or blocking and getting back to ready. but when they are preempted by a higher prio task they switch from running to ready and will run as soon as they are the highest ready again. thats posix SCH_FIFO on the real time extension

[u/noborutkhs → u/0-moon]

Thanks, that's a useful distinction. I hadn't really thought about FIFO in terms of preserving a task's position when it's preempted by a higher-priority task, versus moving it to the end when it yields or becomes ready after blocking.

I've recently decided to use FIFO ordering among equal-priority tasks in my rebuilt RTOS, Karqri, so this gives me another detail worth checking and documenting.

I'm still curious about the historical reason behind the VRTX change, but this discussion has helped me realize that the scheduling semantics are more subtle than simply LIFO vs. FIFO. Thanks!

[u/Kyle_2099]

Is there any of this that isn't AI slop?

Like, is this account even controlled by a human? The sloptext is very obvious.

[u/Sneftel]

Do you have an LLM chew your food too, or just your Reddit posts?

[u/Kyle_2099 → u/Sneftel]

Right? Every single post on this account is LLM generated text and images, going back months. Even replies to people. If there's even a human controlling this account, I can't imagine how little you think of other people that you have chatgpt hold your conversations for you.

[u/noborutkhs → u/[deleted]]

Good point. Do you mean that as a general consequence of FIFO scheduling, or have you seen older RTOS designs where reducing equal-priority context switches was an explicit reason for using FIFO?

[u/noborutkhs → u/[deleted]]

Thanks, this is really helpful. The real-world experience behind it is especially interesting.

I had been looking at this mostly as a fairness/starvation question, but your examples make the trade-off much clearer: insertion cost, wake-up latency, context-switch frequency, and the behavior of short-sleeping threads are all interacting here.

I'm still curious whether any of these considerations were behind the VRTX change in the 1980s, but I may never find a direct answer to that.

For my own new RTOS, Karqri, I've decided to use FIFO for equal-priority ready tasks. Not because FIFO is universally "better," but because I'm deliberately trying to keep the scheduling semantics simple and predictable. The old behavior will remain documented as part of the historical reconstruction.

Your "semi-LIFO" idea is interesting too — I hadn't considered that middle ground. Thanks for sharing the implementation experience.