Let's have a practical example.
A firmware need to create several TLS requests. Each TLS request requires a lengthy crypto calculation, let's say it executes in 3 seconds. Sometimes it needs 1 simultaneous request, sometimes 3 or 5. All requests are equal in importance:
void make_request(destination) {
struct state state;
connect(&state); // Can take a very long time. Uses external crypto library , so cannot be rewritten as FSM
send_request(&state);
read_response(&state); // Can take a very long time
process_reponse(&state);
}
Yeah, it's a typical example. But OTOH, it is an antithesis of what real-time systems are. If you have any real-time requirements, then is it an option to take a black box library which takes "approximately 3 seconds", time-slice it for 3-5 instances which, together, maybe takes 5*3 seconds, on average, with no idea about worst-case timing, and no idea about in which order the function calls finish? Of course not, if it does matter, you just have to dig into the library and write it for your use case, or modify it for real-time needs.
Of course often this does not matter at all, but this is a general purpose computing case, and sounds like a general purpose OS, nothing to do with real-time. Which is the point: there are many reasons why
operating systems exist. But RTOS? All the arguments for RTOS's are for the GPOS (general purpose OS), while the real-time capabilities are pretty unimpressive.
Frankly, given your problem, I would consider the following two options:
* Bare metal MCU, just make make_request a low-priority task (either in superloop, or low-priority ISR), let others interrupt it. If you have five, run it five times; using FIFO request queue for example. This compromises the requirement that if the five TLS requests are pushed into the queue roughly at the same time, they won't finish roughly at the same time, but at ~3 second intervals, in the order they were pushed. But yours won't prove the worst case time or order anyway. Whichever is better is arguable. One could say that the first TLS request from 1.5 seconds ago deserves to be completed first before starting any work on the next one.
* Real computer, real OS. Throw a Raspberry or some more serious industrial PC at the problem. Now it can run full Linux or BSD or whatever, with much greater capabilities and extensibility. Let a separate microcontroller handle all the real-time stuff.
But yours sounds like a valid case for a cheap IoT device: can't afford real computer (price, size, power budget) and that's fine; can't afford real-time designers, and don't need real time design, so that's fine, too -> timing doesn't need to be predictable, no need for complicated software engineering, any developer does, pre-existing code does -> throw a small OS that can run on an MCU at the problem -> it just happens such OS is called "RTOS" -> utilize that in your CV, because NASA did also use RTOS on Mars.