What Makes RTX64 Tick? A Look Inside Our Monitoring Framework
When you are working with RTX64, things can often be a bit opaque. You program something, you compile it into a binary, and then when it comes time to run it, you send it down into this black box and it will, hopefully, do the thing you wanted it to do. Happily, we’re working hard to provide more visibility behind the curtain. Since I started working on this product almost 4 years ago, we have created the debugger which integrates right on top of the Microsoft debugger in Visual Studios. We’ve also created the Monitoring Framework, a subset of APIs within the Vanguard Framework that anyone can use to figure out exactly where and when a program did some very specific operation down to the tick.
In the world of real-time operating systems, you want to know exactly what your operating system is doing at pretty much any given point in the system. Performance, speed and accuracy of when a machine will rotate one rotor or spin a gear make the difference between a smooth production line and turmoil in a factory. So when programming and testing out the code needed to do any number of things, it’s useful to be able to lay out a timeline of how your program performs on the RTX64 OS.
The Monitoring Framework when active will record around 100+ kinds of events to help you determine what is going on behind the scenes of your program. The information gathered is very granular, from showing when a handle is created to when a memory address is freed. The information doesn’t necessarily reflect what the program is doing; rather, it is describing what the subsystem is doing when the user is requesting actions like CreateSharedMemory, or when a program is reading and writing to that location. It will help the user find out when the subsystem actually gets around to cleaning up and how much activity is generated by a program at certain times.
The APIs created to support the monitoring of all these events were pretty simple. The subsystem, while monitoring was turned on, would record a series of binary files into a directory. This would represent a session, and the APIs would then take those binary files and parse them into an object which could be read into a program or just converted in a string. The amount of information generated by the monitoring sessions was daunting to say the least, so we contracted out to Percepio to have them integrate the information generated by our Monitoring Framework into their graphical UI using our robust set of APIs to get the needed information.
The end result turned out really well. We can now see a bird’s eye view of a timeline of events that are separated by which thread they happen on and/or which processor they are executed on. This allows for us, the developers, to get a much faster diagnosis of what’s happening under the hood and isolate where we need to debug. This also allows users to see what their program is doing at exact times of execution, and helps them get an idea of how to improve and optimize their code to run even better on our real-time operating system.