Когда речь заходит о лучших методах разработки компонентов, REDHAWK имеет тенденцию подчеркивать свободу над соответствием. Различные компоненты разрабатываются с учетом различных вариантов использования, и существует много разных подходов к решению проблем в REDHAWK. Это объясняет некоторые различия, которые вы видите между некоторыми компонентами.
Есть ли рекомендуемый компонент Redhawk, который может служить в качестве стандарта: Взятые в целом, Redhawk компоненты размещены на GitHub попытке служить двум целям. Они представляют собой набор полезных компонентов для обработки. И они предназначены как набор примеров для других.
Трудно выделить один компонент в качестве единственного лучшего примера, поскольку каждый из них написан с другой целью и использует разные подходы. Компонент HardLimit, вероятно, является самым простым примером, поэтому полезно понять основные основы разработки компонента. Компонент fastfilter более сложный и демонстрирует некоторые из более продвинутых концепций, таких как блокировка и обратные вызовы свойств, и переопределение конфигурации для проверки на свойства, которые являются взаимозависимыми.
Logging лучшие практики: Короче говоря, при разработке компонентов Redhawk, считается лучшей практики использования Logging вместо этого в System.out/system.error.
В более широком смысле, регистрация может быть сложной темой в REDHAWK. Там действительно нет жестких правил. В общем, все, что происходит «обычно» (например, - получение пакета в служебной функции), должно регистрироваться в DEBUG или TRACE. Все, что находится вне «нормальной» операции, должно регистрироваться как WARN. ERROR используется для непредвиденных ситуаций, которые компонент не должен иметь. Не стесняйтесь следовать рекомендациям log4cxx или log4j при принятии решений о том, какой уровень использовать.
Общей практикой ведения журнала является регистрация предупреждения, когда ввод Q сбрасывается, и это видно на многих компонентах. Свойство журнала свойств реализаций базового класса изменяется в TRACE, поэтому разработчикам компонентов не обязательно будет регистрировать все индивидуальные изменения свойств на более высоком уровне. Тем не менее, они могут выбрать для записи важных свойств в свойстве Callback, если они захотят сделать это (вероятно, DEBUG или INFO будут подходящим уровнем).
Недействительные конфигурации собственности: В Redhawk, Недопустимая конфигурация должна быть выброшен, когда компонент сконфигурирован неверно. Разработчик должен решить, как их компоненты обрабатывают недопустимую конфигурацию свойств для обновления внутреннего состояния. Это дизайнерское решение для разработчиков компонентов. Если вы хотите откатить недопустимое свойство, обратный вызов свойства обеспечивает механизм проверки свойств. Для поплавочной собственности «myProp», код может выглядеть примерно так:
void propChanged(const float *oldValue, const float *newValue)
{
bool valid(true);
// add custom logic to check the value here and set valid to false
// For example, here is a check to ensure the property is postive:
if (value<0)
valid =false;
if (!valid)
{
LOG_WARN(comp_i, "myProp received invalid value"<< *newValue);
myProp=*oldValue; //reset property to original value
throw std::exception();
//this causes base class to throw invalidConfiguration
}
//any additional logic for updating the component after the change goes here
}
В некоторых случаях вы не можете сбросить значение в OldValue, вы можете установить его в значение по умолчанию (например - установка отрицательных чисел на 0). Все это зависит от усмотрения разработчика. В некоторых случаях вам может понадобиться округлить значение до определенного допуска (например, округление до ближайшего .001) и вообще не выбрасывать недопустимую конфигурацию.
темы изменение в безопасности собственности: параллелизм резьбы в процессе конфигурации свойств невероятно важно и должны быть рассмотрено для всех свойств. Базовые классы используют mutex «propertySetAccess» для блокировки во время настройки и запроса, что обеспечивает простой способ блокировки и сохранения любых свойств от одновременного изменения дополнительной обработки. Однако это не рекомендуется, потому что существуют различные подходы к обработке параллелизма свойств, а блокировка для всех обновлений конфигурации свойств в большинстве случаев является чрезмерной. Кроме того, стоит отметить, что при блокировке этого способа блокировка сохраняется во время обратного вызова свойства, поэтому нет необходимости, чтобы обратные вызовы повторно фиксировали блокировку.
Для некоторых свойств может не иметь значения, изменяется ли значение в середине обработки пакета данных. Хорошим примером являются «upper_limit» и «lower_limit» в HardLimit. Разработчик решил, что для этих значений не важно изменить среднюю обработку, и для этого компонента не существует параллелизма свойств.
Для некоторых свойств, таких как «fftSize» в fastfilter, дизайнер решил, что они никогда не хотели, чтобы это значение меняло среднюю обработку. Таким образом, у них есть отдельный мьютекс, filterLock_, чтобы этого не происходило.
Другой вариант вместо блокировки - сделать локальную копию свойства, а затем использовать эту копию на протяжении всей обработки. Когда свойство изменяется в середине цикла, новое значение будет применено в следующей служебной функции.