Real Time Execution

[kjemeyer]

I am not sure if I am doing this right, but it would be great to upper bounds on execution of code paths. if there were some way to normalize impact of cache, assign time cost to acquiring and releasing resources, analyze the assembly and give upper bound on number of instructions in assembly for code for a given processor, and use cpu frequency as a input, it seems with some degree of fidelity you could statically give a time profile to code.

[kjemeyer]

could we add a real-time.md profile?

[kjemeyer]

for example a code path that does a lot of dynamic allocation would have a lower relative real time profile versus a code that does no dynamic allocation.

[Bjarne Stroustrup]

Such a profile would be nice, but hard to devise. Execution time depends on the processor, the state of the caches, the state of the free store , the quality of the optimizers, etc. so we can't even be sure that two executions will have the same performance. A upper bound would be much higher that the average time for many interesting cases. But yes, the upper bound is essential to some uses (e.g., real time response) so such a profile would be very nice to have.

[Thibault]

In a similar land, would this profile include provisions for the enforcement of various dynamic allocation policies?

To be more specific, in mission-critical embedded systems it is usually essential to ensure that particular modules refrain from using any memory allocation, or that dynamic memory allocation is only limited to constructors until the subsystem has been initialized to a stable state.

[Ben Boeckel]

It is my understanding that the more important point is that there is no possibility for "interruption" during critical sections in realtime applications. So a bump allocator (with guarantees about availability) may be fine, but brk()-backed allocators not. One might want to instead have a rule about "no suspend points" in such code because then you are at least only at the mercy of your own generated assembly when comparing against the wall clock.

[Marek Zukal]

I tried to isolate the previously mentioned metrics into independent categories that might be considered separately based on their usability and difficulty to provide or define.

Boundaries

• execution-cost - cumulative instruction / clock path boundary
  • independent on cache state - could be its own metric
  • independent on CPU frequency
  • can provide a path cost analysis cut-off - if more than x is considered unbound
• stack-use - cumulative stack usage boundary
  • can utilize internals that provide -fstack-usage
  • might be relevant to memory-safety profile as well
• heap-use - cumulative allocation boundary
  • can be restricted to forbid allocation completely
  • might be relevant for memory-safety profile as well

Other guarantees

These can be relevant to real-time in some cases but might be relevant to concurrency profile as well.

• no-external-call - no blocking or scheduling system calls nor external libraries that do not provide the same guarantees
• interruptible - does not prevent interrupts
• isr-safe - can be called from an interrupt handler

Custom attributes

Thinking about the variability of various guarantees I need to ask would it make sense to have an option to create user defined attributes. That could help provide support for guarantees, that are too specific to be standardized but might provide the needed functionality on specific architectures or for specific use cases. I imagine a mechanism, that would allow a block of code call only functions, that have a specific attribute set.