On Wed, May 12, 2021 at 8:48 AM Michael Wong via SG14 <sg14@lists.isocpp.org> wrote:
As of the Apr 2021 discussion on low latency general brainstorming chaired by  Staffan TjernstrÃm  , captured in notes here: 
https://lists.isocpp.org/sg14/2021/04/0616.php

This is  a summary of that discussion aiming to elicit more refinement, leading to possible features:
  1. - issues/problems of the domain in C++
    1. need to access hardware features, memory card, I/O controller, DMA, is low latency an  upper bound or determinism
    2. competing with some OS services but not served by all OS 
    3. C++ can offer standard APIs to query for facility
  2. - Features/proposals for C++
    1. thread priorities
    2. cache-control
    3. scheduling periodic thread intervals or by the deadline
    4. CPU pinning like madvise
    5. manage memory-mapped files
    6. Vulkan-like capability model that fits specific hardware
    7. enforce the real-time constraint on a call path or trap at runtime if unable to satisfy
Please feel free to add to this discussion with more issues/proposals, and more details with possible proposals.

Another point (raised in the past by Nial and others) is to recommend that C++ "standard" APIs (such as those provided through "std::"):

* Prefer APIs that accept memory as-passed-in by the caller, rather than rely upon internal allocation semantics, or reliance upon allocators.

By defining APIs that demanded already-allocated-memory as parameters, we could:

(a) better control latency (e.g., the implementation does not even attempt an allocator-call with possibly variable-length duration)
(b) better leverage hardware-specific resources (e.g., hardware-specific APIs are leveraged external to the "std::" implementation)

--charley