Миллионы объектов со стабильными адресами, или как удержать состояние под строгим RT дедлайном цикла
Рассмотрим класс задач, который встречается в разных областях. Долгоживущий процесс держит состояние из нескольких миллионов объектов по 2 КБ каждый. На это состояние напрямую указывают и другие потоки, в том числе внешние, и заменить эти указатели копированием или доступом через менеджер не позволяет сама архитектура. Например, потокам интерфейса с аппаратной частью нужно читать данные в реальном времени, без какой‑либо синхронизации с главным потоком. Рядом крутится цикл обработки событий, и его итерация обязана завершаться за десять миллисекунд. Это строгий RT дедлайн. Такая связка требований почти не оставляет выбора в организации хранения и управлении таймерами. Ни один стандартный контейнер не закрывает все свойства сразу. И каждое упущенное свойство на таком масштабе превращается либо в уязвимость, либо в срыв дедлайна. Статья расскажет о двух технических решениях, которые закрывают эти задачи. Первое даёт хранилище, в котором адрес записи неизменен всё время её существования. Второе ограничивает обход только активными объектами. Решения взяты из реального проекта, библиотеки‑ядра libgsml3parser для построения программной GSM/2G базовой станции. Там роль объекта играет сессия абонента, а 3GPP правила задают конкретные таймеры. Оба решения переносятся на любую систему того же класса ограничений почти без изменений. Читать далее
