Для разработчиков, заинтересованных в использовании C ++ в системах реального времени, есть как хорошие, так и плохие новости. Во-первых, плохие новости: проблемы, на которые ссылаются Гуч и Торвальдс, все еще актуальны и сегодня.

Ричард Э. Гуч : «Я лично считаю, что C ++ имеет свои преимущества и облегчает объектно-ориентированное программирование. Тем не менее, это более сложный язык и менее зрелый, чем C. Самая большая опасность для C ++ - это его мощь. Это соблазняет программиста, делая его намного проще для написания вирусов. Ядро является важной частью кода и должно быть быстрым и быстрым. Мы не можем позволить себе раздувать. Я думаю, будет справедливо сказать, что для написания эффективного кода на C ++ требуется больше навыков, чем на код на C. [Разработчики] не будут знать о различных хитростях и ловушках для создания эффективного кода C ++ ».
Линус Торвальдс : " Поверь мне - написание кода ядра на C ++ - это ИДЕЯ КРОВИ ГЛУБОКОГО. Фактически, компиляторы C ++ не заслуживают доверия. Вся вещь, связанная с обработкой исключений в C ++, принципиально сломана. Это _ особенно специально для ядер. Любой компилятор или язык, который любит скрывать такие вещи, как распределение памяти за вашей спиной, просто не очень хороший выбор для ядра ». (цитируется в Linux-Linux FAQ)

Тем не менее, разработчики на C ++ по-прежнему «соблазняются» мощными и гибкими библиотеками и языковыми функциями, которые могут «раздувать» ваш код, и мы все еще должны осознавать «хитрости и ловушки», чтобы избежать «таких вещей, как распределение памяти за вашей спиной».

И это определенно не новая проблема, когда речь идет о встроенных системах и системах реального времени. Более 10 лет назад был большой интерес к подмножеству C ++ под названием « Встроенный C ++ »Предназначенный для решения таких проблем, но эти усилия натолкнулись на возражения со стороны создателя языка С ++ Бьярно Страуструпа и не прижились.

Хорошие новости о C ++ . Сообщество разработчиков C ++ работало над этой проблемой почти десять лет с тех пор, как была написана цитата из Gooch, и теперь общее понимание этих проблем намного лучше. Ответственные, опытные разработчики реального времени теперь считают C ++ жизнеспособным вариантом для систем реального времени.

«Уловки и ловушки», которые могли быть «за вашей спиной» пятнадцать или даже пять лет назад, теперь становятся общеизвестными в организациях, которые заботятся о качественном коде C ++ в режиме реального времени, и многие организации теперь соответствуют этому описанию (поиск Google для « C ++ в режиме реального времени »появляется много объявлений о работе). Моя цель - поделиться некоторыми основными моментами из опыта работы с такими проектами, которые иллюстрируют предостережения относительно некоторых часто используемых функций языка C ++.

В режиме реального времени встречается стандартная библиотека шаблонов
Любой разработчик C ++, который вышел за пределы "cout <<" hello world "<< ebd1l", сталкивался со стандартной библиотекой шаблонов, или STL.

Стандартная библиотека шаблонов, исключения, шаблоны, интерфейсы и другие функции языка очень важны для разработчиков на C ++, но их легко можно использовать неправильно, в реальном времени, и иметь побочные эффекты, которые могут быть неочевидны для разработчики в реальном времени думают о переходе с C на C ++.

Как вы знаете, STL - это набор структур данных и алгоритмов C ++, которые являются частью всех реализаций C ++. Как и следовало ожидать от любой библиотеки общего назначения, она включает в себя широкий спектр функций и имеет различные компромиссы при использовании в системах реального времени, многие из которых, но не все, документированы в спецификации, справочном материале, таком как Stroustrup's C ++ Язык программирования и в Интернете (т.е. ссылки на STL, на которые я ссылаюсь в этом документе, любезно предоставлены SGI и другие).

станд :: вектор
Типичное обсуждение STL начинается с вектор класс, и наш тоже. Вектор часто используется в качестве отправной точки, потому что это один из простейших классов STL, функциональность которого можно довольно кратко описать как «массив динамического изменения размера».

Эта простота также помогает сделать его очень эффективным контейнером, что является одной из причин, по которой он может попасться на глаза разработчику реального времени. Однако основная причина, по которой он должен быть заметен в репертуаре разработчиков в реальном времени, заключается в уникальности вектора среди классов STL: заданное управление памятью.

В отличие от других контейнеров STL, вектор имеет метод, резерв, вручную выделить память и связанный метод, вместимость, извлечь объем памяти, выделенный в данный момент (который может или, скорее всего, может не соответствовать размер вектора). Это позволяет вам, как разработчику в реальном времени, четко следовать важной практике проектирования в реальном времени, предусматривающей выделение всей памяти «заранее», до того, как это необходимо, и позволяет ограничить использование функциональности динамического изменения размера вектора.
для некритических потоков.

Это, в свою очередь, позволяет вашему критичному по времени коду воспользоваться преимуществами эффективной функции доступа к вектору вектора, не беспокоясь о векторе с помощью диспетчера памяти за кулисами. Избегать менеджера памяти в коде реального времени, очевидно, желательно, так как это обычно общий ресурс со связанными проблемами инверсии приоритетов и недетерминированности.

Примечательным примером того, как STL не может обеспечить эту функциональность управления памятью, является Deque. Этот класс добавляет вставку / удаление в постоянном времени из передней части контейнера и поэтому часто подходит для представления очередей и FIFO - особенно полезной абстракции в реальном времени и встраиваемом программном обеспечении, поскольку эти концепции хорошо соответствуют поведению оборудования.

Однако deque разочаровывает, потому что в отличие от вектора (но, как и большинство типов STL), он не предлагает резервной операции для ручного запроса памяти. Это досадное упущение делает этот, казалось бы, полезный контейнер неподходящим для программного обеспечения реального времени без особой осторожности.

Во время обсуждения и иллюстрации резерва выше вы, возможно, заметили, что нет операции без резерва. Фактически, не существует векторного API, специально предназначенного для освобождения неиспользуемой памяти, зарезервированной в векторе. В языке программирования C ++ , раздел 16.3.8, Страуструп описывает механизм для этого как «маленький трюк»:

vector <int> tmp = v; // копия v с емкостью по умолчанию
v.swap (TMP); // теперь v имеет емкость по умолчанию

Обратите внимание, что vector :: clear определено как эквивалент vector :: erase (begin (), end ()), который не освобождает память. Некоторые несовместимые реализации clear просто выполняют подкачку с пустым вектором в качестве оптимизации, которая освобождает память.

Одним из важных предостережений с использованием вектора в системах реального времени является специальная обработка стандартной библиотекой векторов булева типа C ++, то есть vector <bool>. В отличие от приведенной выше иллюстрации, вектор bool хранится в битовом формате, что является оптимизацией для экономии памяти, поскольку для хранения логического значения не требуется целый байт или слово.

Это представляет интерес для разработчиков в реальном времени, потому что мы часто имеем дело с битами (при обращении к аппаратному обеспечению), а память стоит дорого (поэтому экономия места при упаковке битов является привлекательной). Как вы можете видеть, однако, вы быстро столкнетесь с проблемами в этом специализированном поведении.

Например, код, который отлично работает с другими векторами, не будет работать (может не скомпилироваться, может произойти сбой и т. Д.) С векторами bools, потому что вы не можете получить обычную ссылку на bool, который содержится в векторе <bool> - вы необходимо использовать содержащийся прокси-класс вектор <BOOL> :: ссылки. Более того, большая часть эффективности и простоты, которые так важны для полезности вектора, теряются в этой специализации, что приводит к неожиданным потерям производительности.

Обратите внимание, что термин «специализированный» выше имеет конкретное значение в коде шаблона C ++: он означает, что кто-то (в данном случае, сама библиотека) явно реализовал версию шаблона для данного типа, переопределяя нормальное поведение шаблона для этого типа. Прошлое и будущее этой конкретной специализации широко обсуждаются в Интернете.

Суть в том, что он был введен в качестве примера некоторых языковых возможностей для решения актуальных проблем; он не решает чисто проблемы, для которых он был предназначен; и комитет по стандартам уже много лет пытается найти хороший способ исправить эту ошибку. Самое простое правило - просто избегать этого; STL также определяет BitSet класс, который больше подходит в большинстве случаев использования.

станд :: список
Мы продолжим с традиционным потоком разговоров STL и перейдем к типу связанного списка, список. Это тип списка STL с двойной связью, и он обеспечивает часть ключевой функциональности, которую вы ожидаете от такой структуры данных: в основном, вставка / удаление элементов из списка не делает недействительными итераторы для элементов, отличных от тех, которые непосредственно затрагиваются операцией в рука.

Однако есть еще одна важная часть того, что нужно разработчикам в реальном времени из этого контейнера, которая не соответствует ожиданиям: каждая операция вставки / удаления, использующая стандартные методы вставки и стирания STL, может обращаться к диспетчеру памяти. Это делает эти операции, которые определены как «амортизированное постоянное время», недетерминированными.

Первый и самый простой способ обойти этот доступ к памяти - это использовать Список :: сращивания метод. Сплайсинг списков позволяет перемещать элементы или разделы списка в другой список, обычно за постоянное время, без управления памятью. Этот метод позволяет потокам в реальном времени управлять списком детерминистически, оставляя любую недетерминированную инициализацию или очистку не критичным ко времени потокам. Например, поток в реальном времени может обработать элемент списка и затем объединить его из «активного» списка в «завершенный» список, а служебный поток будет тогда отвечать за заботу о «завершенных» элементах, в том числе освобождение элементов списка.

Другое решение состоит в том, чтобы отойти от основного списка STL и использовать навязчивую реализацию списка, которая полностью исключает управление скрытой памятью в классе списка. В то время как списки STL позволяют использовать пользовательский распределитель, который также мог бы дать разработчику лучший контроль над распределениями, как мы увидим ниже, написание пользовательского распределителя STL достаточно сложно, чтобы быть необоснованным для большинства ситуаций.

Напротив, навязчивая реализация, такая как Boost.Intrusive работает путем включения необходимых накладных расходов на управление списками непосредственно в содержащиеся элементы, делая управление памятью явным без хлопот с пользовательским распределителем.

Удобно, что навязчивые контейнеры могут в значительной степени соответствовать интерфейсу STL для эквивалентных типов. Есть несколько заметных исключений, таких как ограничения на наличие узла в нескольких навязчивых контейнерах одновременно, что означает, что контейнеры STL предпочтительны, где это возможно; если навязчивый контейнер уместен, его документация, как правило, разъясняет любые отличия от интерфейса STL.

Когда вы помещаете элемент типа T в контейнер STL, такой как список, вы получаете поведение, показанное на рисунке ниже:

Если вы не хотите, чтобы данные копировались (например, потому что они не копируемые, или полиморфного типа, или неэффективные для копирования), вы в конечном итоге поместите указатель на свои данные в контейнер, показанный на Рисунок ниже:

В этом случае при использовании контейнера STL все еще выделяется память, поскольку сам указатель должен быть скопирован в контейнер. Интрузивная реализация избегает этого, отслеживая данные «контейнерного узла», такие как следующий и предыдущий указатели списка, внутри самого типа узла, как показано на рисунке ниже:

Конечно, недостатком является то, что данные узла контейнера «внедряются» в тип вашего элемента. Интрузивные контейнеры позволяют обойти это, предоставляя оболочки или базовые классы для данных узла, как показано на рисунке ниже:

Тем не менее, у этого подхода есть важные ограничения, главным образом, из-за того, что вы теперь несете ответственность за синхронизацию времени жизни узла данных с его использованием в контейнере. В целом, навязчивые типы контейнеров являются важной частью набора инструментов разработчика C ++ в режиме реального времени, но не всегда подходят для всех ситуаций.

Как разработчик в реальном времени вы также можете рассмотреть возможность добавления SLIST к вашему набору инструментов. Это односвязный тип списка STL, и он может быть полезен в чувствительных к производительности приложениях, где двунаправленная итерация списка не требуется. Узел в односвязном списке меньше в памяти и может обновляться с меньшим количеством операций, чем узел в двусвязном списке, подобном списку.

С другой стороны, хотя slist предоставляет все обычные операторы для контейнеров STL, такие как вставка и стирание, эти соглашения по соглашению STL должны влиять на элемент перед итератором, передаваемый методу.

Очевидно, что это включает патологически медленную итерацию списка, поэтому slist предлагает новые функции-члены insert_after и erase_after, которые могут выполняться в постоянное время (вместо того, чтобы выполнять итерацию списка, чтобы найти элемент перед указанным итератором, он работает с элементами сразу после итератор, который легко найти).

Другим следствием отсутствия обратного итератора в slist является то, что splice больше не является постоянным временем и фактически может быть очень медленным, как вставка и стирание, что делает этот полезный метод списка неподходящим для slist. Вместо этого используйте splice_after, дружественный к слайстам эквивалент.

Работа с ассоциативными контейнерами
STL предоставляет очень привлекательную библиотеку ассоциативных контейнеров, которые предоставляют возможность эффективно искать конкретный элемент, либо используя сам элемент в качестве ключа ( задавать ) или с помощью произвольно набранного ключа в паре с каждым значением ( карта ). Оба из этих ассоциативных типов контейнеров имеют варианты, которые допускают несколько элементов одного и того же ключа (т.е. мультимножеством ) и варианты, которые ищут ключи в хэш-таблице вместо дерева по умолчанию (т.е. hash_map ) для обеспечения более быстрого поиска за счет отсутствия сортировки (и, следовательно, неприемлемого для использования в алгоритмах STL, таких как set_difference ).

Все это - многословный способ сказать, что ассоциативные контейнеры STL предоставляют множество действительно мощных функций в довольно простом интерфейсе, который знаком всем, кто использует vector и list.

В этот момент вы, без сомнения, вспоминаете цитаты из начала статьи о стремлении C ++ абстрагировать сложные функциональные возможности и, как следствие, скрытое в реальном времени скрытое выделение памяти и раздувание кода. Ассоциативные контейнеры - это то, где мы действительно начинаем чувствовать эту боль. Простейшим примером этого, который действительно может застать разработчика C врасплох, является следующий фрагмент:

void set_value (map <int, string> & m, int key)
{
m [key] = "value"; // выделяет память
}

То есть то, что кажется простым присваиванием с оператором [], выделит память (если m не содержит ключа), классический пример C ++ - это « язык, который любит скрывать такие вещи, как распределение памяти за вашей спиной », как утверждал Торвальдс ,

Эта ситуация еще хуже для систем реального времени с этими контейнерами, потому что выделения и связанные освобождения имеют непредсказуемый (но, вероятно, небольшой) размер и допускаются спецификацией в непредсказуемые моменты времени. Это приводит не только к недетерминированности, инверсии приоритетов и ко всем проблемам, о которых вы сразу подумаете при рассмотрении управления памятью в системах реального времени, но также к необычно серьезным проблемам фрагментации памяти и локальности кэша.

Приведенный выше пример иллюстрирует другой домен, в котором ассоциативные контейнеры начинают вызывать непредвиденные проблемы: размер кода. В системах реального времени и встраиваемых системах размер кода довольно быстро достигает нижнего предела, так как он влияет на требования к оборудованию, такие как объем диска, использование памяти, время загрузки, и характеристики процессора, такие как размер кэша.

Мы обсудим это более подробно ниже, так как эта проблема может влиять на код C ++ по разным причинам, и существуют инструменты, помогающие диагностировать и исправлять эту проблему, но карта предоставляет хорошую возможность представить проблемы.

Рассмотрим приведенный выше фрагмент, однострочную функцию set_value. Компиляция этой однострочной функции с версией g ++ для VxWorks 6.3 приводит к получению двоичного файла длиной 55,440 байт без символов отладки (что, следует отметить, требует некоторого #includ e и использования директив, которые не показаны).

Напротив, аналогичная функция C, которая использует ключ для индексации m в качестве простого массива из char *, компилируется до 828 байт (конечно, это не совсем справедливое сравнение, когда дело доходит до функциональности, но величина разницы является иллюстративной) , Есть несколько причин, которые обсуждаются позже, но одна большая часть этого - вся «магия», скрытая в библиотеках STL. Чтобы подогреть аппетит, рассмотрим этот отрывок из одного инструмента, который мы можем использовать для исследования таких проблем, который сообщает размеры символов в двоичном виде:

0000035c W std :: _ Tree <…> :: Buynode (…)
000003a4 W std :: _ Tree <…> :: insert (…)
000004b0 W std :: string :: _ Copy (…) 00000718 W std :: _ Tree <…> :: insert (…)
00000a74 W std :: _ Tree <…> :: _ Insert (…)

Первый столбец - это размер каждой функции. Это всего лишь 5 самых больших функций (самая большая - 2676 байт, десятичное число) из 101 символа, сгенерированного этим простым фрагментом кода; опять же, напротив, двоичный вывод из аналогичного кода C генерирует только одну функцию, собственно set_value, с 64 байтами кода.

Хотя «раздувание» очевидно в этом тривиальном примере, важно знать об инструментах, которые можно использовать для отслеживания этих проблем - даже здесь само значение set_value в коде C ++ составляет 112 байт, на самом деле не намного больше кода, чем версия C и только 1 из 5 самых больших символов реализует тип, который мы явно использовали в коде (строке), что может дать вам начальное представление о том, насколько сложно найти и исправить проблемы с избыточным размером кода, вызванные неправильным использованием библиотек, таких как STL.

Последняя проблема, связанная с картой относительно нашей проблемной области, заключается в том, что ее использование может быть затруднено безопасным способом. Причина этого заключается в том, что вставка карты обычно выполняется с помощью удобного оператора [], который имеет два эффекта: создание новой пары ключ / значение на карте и присвоение ей значения. Необходимо соблюдать осторожность для обработки сбоев на любом этапе, не вызывая проблем на другом этапе.

Некоторые из этих проблем присущи мощности ассоциативных контейнеров и влияют на любой код, который реализует хеш-таблицу или структуры данных красно-черного дерева, которые формируют основу контейнеров STL. Другими словами, если вам нужна эта функциональность, у вас будет много кода для ее реализации.

STL - это, во всех отношениях, довольно эффективная реализация предоставленной функциональности, и я бы вообще не рекомендовал пытаться реализовать ее самостоятельно. Тем не менее, есть инструменты, которые вы можете применять для устранения недостатков этих классов, либо путем осторожного использования предоставленных типов, либо путем получения STL-подобной функциональности из другой реализации, которая решает конкретный вариант использования.

Одним из способов решения этих проблем является использование навязчивого контейнера. Boost.Intrusive реализует некоторые из ассоциативных контейнеров, и мой коллега Ирван Джаджади реализовал STR-подобный набор интрузивных контейнеров («ITL»), включая реализацию навязчивой карты, которую мы используем для управления распределением памяти, связанным с картой.

Навязчивая карта сложнее, чем навязчивый список, потому что внутри она использует красно-черный дерево, поэтому каждый узел имеет цвет и три указателя (родитель, левый и правый дочерние элементы). Кроме того, контейнерный узел для навязчивой карты включает ключ, используемый для ссылки на данные. ( Почему? Цель наличия карты - связать ключ с частью данных, но смысл навязчивого контейнера - избежать выделения памяти. Таким образом, реализация должна скопировать ключ в узел контейнера, встроенный в ваши данные. )

Здесь важно отметить, что если тип ключа, который вы используете, является сложной структурой данных, которая выделяет память во время операции копирования, вставка в навязчивую карту будет выделять память во время операции копирования ключа, поэтому такого типа ключа следует избегать ,

Обсуждение навязчивых списков, приведенных выше, включало общую иллюстрацию неинтрузивных контейнеров, которая также применяется к ассоциативным контейнерам. Для сравнения, на следующем рисунке показана навязчивая карта с несколькими узлами, где каждый узел уже содержит все данные, необходимые для использования на карте, даже если ее нет на карте:

Этот навязчивый тип карты решает проблемы выделения памяти, рассмотренные выше, такие как конфликт диспетчера памяти, фрагментация и скрытые выделения. Такая реализация пользовательской карты может также решить некоторые проблемы с размером кода, поскольку может быть допустимо оставить некоторые функции STL нереализованными, хотя наш класс навязчивой карты довольно завершен, поэтому мы не ожидаем значительного улучшения в этой области.

Дополнительные преимущества включают в себя тот факт, что теперь вставка может обеспечить беспроблемную гарантию, а также значительно повысить производительность в приложениях, которые позволяют использовать этот тип карты, как показано на рисунке ниже:

Как и в случае класса навязчивых списков, существуют ограничения на то, когда вы можете и должны использовать навязчивые ассоциативные контейнеры. Если ваши элементы должны присутствовать во многих контейнерах одновременно, «вторжение» данных для каждого контейнера станет проблематичным. Вам необходимо синхронизировать время жизни элементов с их участием в контейнере. Также стоит отметить, что некоторые контейнеры (например, вектор) имеют требования, несовместимые с навязчивой реализацией.

Выше мы обсуждали, что осторожное использование существующих ассоциативных контейнеров STL также может быть жизнеспособным решением для некоторых недостатков. Например, давайте подробнее рассмотрим проблемы, которые могут возникнуть из-за удобной операции назначения карты, которая фактически выполняет две отдельные операции (выделение карты и копирование значения) в одну строку:

my_map [key] = new X;

Эта или любая другая вставка карты с оператором [], чья правая сторона может бросить, может оставить карту в состоянии, в котором новый ключ / значение был создан, но никогда не назначен. Компилятор может сначала оценить левую часть, создав новый объект на карте, прежде чем столкнется с исключением. Вы можете попытаться обойти это с помощью умного указателя, но вы все равно должны быть осторожны. Например, вы можете попробовать:

значение std :: auto_ptr <X> (новый X);
my_map [key] = value.release ();

Это не решает проблему, поскольку компилятор также может свободно оценивать стороны назначения в другом порядке, что приведет к потере интеллектуальным указателем контроля над новым объектом до его успешного копирования в карту. Если оператор карты [] затем выбрасывает (из-за нехватки памяти), новый объект пропускается. Самое безопасное решение - использовать тот же умный указатель, но освобождать его только после успешного назначения:

my_map [key] = value.get ();
value.release ();

Подобная логика применима в различных других контейнерных операциях STL, где и типичное назначение, и распределение происходят «сразу». Например, использование vector :: push_back может выиграть от этого типа тщательного кодирования.

Похожие

Комментарии