So... I think you may be asking the wrong question.

What you linked has little to do with being an RTOS. What is described is actually something relatively new (to the non-academic or research world at least) called memory resident computation. It's schtick being that it throws out the primary throughput limiter of the Von-Neumann computing architecture (the FSB, or the pipe traditionally feeding the CPU, which is generally the primary transformer of data in a computing system) with specialized circuitry embedded directly in Main memory. Your major issue though, is you still need to create a coherent "machine" around it. A bunch of circuits does not a useful computer make if you (the programmer) cannot reasonably tell or reason about what you are trying to do.

Computing is built off of primitives. All high level functionality is fundamentally orchestrated sequences of state micromanagement that when done have a defined start point, end point, and do not violate any of the myriad constraints that your computer cannot recover from. The most important roadblock in Memory resident computing (as far as I'm aware) is that no one really has their head wrapped around what a program using it would look like in light of current computing primitives, or the set of extra primitives required to be implemented to result in a sufficiently robust and stable machine that you can even think of making use of it.

From your processor's point of view it's be like casting a brick with a sticky note taped to it to main memory on the FSB (probably specialized opcodes in a newly implemented MMU) then going off and doing something else until a brick with an ack or a complete signal comes back with an indicator that something is done. That's a drastic oversimplification though, because there are so many problems there when you layer on all the things that can go wrong when you mix special in memory computing programs with programs and systems written which are completely unaware of the fact that by hard page-faulting and swapping out memory contents to keep that other system service running, they are hosing an in-memory computation. In fact, that in-memory computation may be completely unaware of or unable to signal that it doesn't have something, or know how to safely ask the MMU to get what it needs, because most of those primitives are only written in the single CPU actor paradigm.

You have to fundamentally shift how you think about computing from having one caffeine fueled savant shifting things around, to potentially having thousands of them, all unaware of the other's existence. It isn't terribly unlike my recent attempts to wrap my head around management honestly.

I'll be the first to admit I'm not read up on the cutting edge in this area. Maybe there are a few PhD's out there that have something like that rolled in a lab. I'm just not aware of any serious uptake, because most commercial non-academic use is more incentivized around "safe" bets on sinking money to develop further. In computing, I've noticed that good advances tend to follow someone having a breakthrough understanding of how a process works or is implemented with just humans. Understanding one actor processes is trivial compared to 2+ actors. It's an interesting problem space to be sure.

Or... I completely misunderstood what you're asking. That happens a lot too.