Real-time Programming with the C++ Standard Library – Timur Doumler – CppCon 2021


In applications such as video games and audio processing, a program has to not only produce the correct result, but to do so reliably in a deterministic amount of time. The code needs to satisfy real-time constraints, complicated by the fact that it will typically run on a non-real-time OS kernel. Writing code for such constraints significantly differs from writing code that maximises for bandwidth or overall performance.

How well suitable is the C++ standard library for such scenarios? In this talk, we will go through many of its facilities in detail. Which are safe to use in (near-)real-time contexts? Which should be avoided, and why? We will discuss well-established utilities and useful patterns as well as some less commonly known details.

This talk is a different kind of tour through the standard library – and afterwards, you will be more confident in using it!

Timur Doumler is the Developer Advocate for C++ at JetBrains. As a developer, he specialises in audio and music software. Timur is an active member of the ISO C++ standard committee, co-founder of the music tech startup Cradle, and conference chair of the Audio Developer Conference (ADC). He is passionate about building inclusive communities, clean code, good tools, low latency, and the evolution of the C++ language.

Videos Filmed & Edited by Bash Films:

YouTube Channel Managed by Digital Medium Ltd

The CppCon YouTube Channel Is Sponsored By:
JetBrains :


About Author


  1. I suggest an additional (optional) parameter to the attribute:
    [[realtime_safe(n*m)]] void do_sth(int* array2d, int n, int m);

    In general attributes for runtime might be useful, which would allow more complex code analysis:

    [[average_time(n*std::log(n)), worst_time(n*n)]] void sort(…);

    I guess compilers could bubble up this attribute through callers, such that tools can show the runtime behavior of any function.

  2. by definition, real-time does not equal to low-latency, although most of time people tend to use interchangeably. Real-time is a deterministic characteristic.

  3. 49:10 are we seriously considering the possibility of rolling same INT_MAX value like a thousand times in a row? for it to be a noticeable performance hit

  4. 54:30 std::atomic itself might add memory fences or hardware locks depending on the std::memory_order. You can't have lock free data structures without these. Luckily, there is no reason why they shouldn't be real-time safe. They work on the CPU level, not on the OS scheduler level.

  5. 38:48 Is waking up a thread really a problem in practice? If you do multi-threaded DSP, you always have to synchronize threads. The helper threads typically wait on a semaphore and the "main" audio thread posts to the semaphore to wake them up. How would you do this if you were not allowed to wake up threads?

  6. Most important I think here is avoid using std containers ( or maybe with a custom preallocator ) , and anything else appart from atomic in multithreading . I did not know actually stdarray is allocated on the stack good info there .

  7. This guy has an unwarranted phobia of multi-threading. What guarantees are there that his beloved single thread won't be interrupted and re-scheduled by the OS? None. I'd rather make my app faster with multi-threading and thus more "realtime".

  8. This was an excellent talk – this topic is very rarely covered at this depth – extremely useful for my interest in C++ audio DSP on ARM – thank you.

  9. There were a lot of primitives from the thread support library getting tossed out. I wish there was a bit more time spent going over why. Having worked in an RTOS environment, posting semaphores or a msg to a queue seems like a common thing to do from a high priority thread.

  10. Fantastic talk! The audio quality is great. Your talk has a constant level of abstraction, this makes it easy to follow and absorb. You mention where there are rabbit holes and give a summary of your findings, that's so efficient. Your slideware greatly supports your narrative, is short and precise. The overall narrative visits topic after topic, giving an overview, some examples, some details, some outlook (like inpace_function, static_vector) and mentions the standard or papers where useful. One of the best talks of CppCon 2021! I have nothing to do with audio but I enjoyed it beginning to end.

  11. Fascinating talk, thank you for this.
    If applicable, and where the problem areas are 'small'/manageable, would writing those sections in assembly language give you your required predictive execution behaviour? Of course, it would help if kernel calls are not used, or if used, they don't re-introduce what you seek to prevent. We used to re-write specific (problematic) kernel routines in days gone by – mainly removing their general purpose nature for our specific use cases(and gaining significant speed and 100% behavioural predictability)…don't know how doable that is here/today. A damn shame if those days are gone. Today's abstraction is both good and bad (loss of control, predictability, etc)

  12. the best true random number generator ive seen is a reverse polarity base emitter junction in a bjt with non connected collector connected to an ADC…

  13. technically you could do algorithms that are linear or worse in time complexity if you know that your input is within a given range for that the time complexity is within the deadline (or rather some percentage thereof)

  14. I find it sad that it's 2022 and Timur still has to dispel the "lambdas heap allocate" myth. Lambdas have been in the language for more than ten years at this point. How many CppCon talks pointing this out is it going to take before we can stop re-explaining all this?

Leave A Reply