RH特性的最佳实践

Question

关于RH块的最佳实践，我有几个问题。

首先，在redhawksdr github中是否有一个块可以作为所有RH模块应该遵循的关于应该如何完成事情的例子？我在redhawksdr gitub站点上看到了许多块，每个块似乎都以不同的方式处理日志记录和错误。有些还没有删除默认生成的日志语句。

我们应该记录所有的属性更改吗？使用1.10中的新属性回调，很容易记录从旧的到新的转换。如果是的话，我应该将它们记录到哪个日志级别(例如调试或信息)？其他人在做什么?为什么？

如果尝试设置属性，但无法应用新设置，我们是否应该抛出异常并忽略新设置？我们是否应该记录错误或警告，并确保没有异常从组件中传播出来？这些消息应该在什么日志级别？我看到github上的几个街区打印到cerr，什么也不做。那些在实践中已经使用RH的人推荐的方法是什么？

通常，我们是否应该创建块，以便属性更改是完全发生或块的内部状态根本不发生变化的事务。在用于redhawksdr的github上的一些块中，它们将尝试更改属性并打印错误，但此时状态并没有很好地定义。这在总体上是可以接受的，还是我们应该在这方面使所有事务级别完全安全？

Answer 1

当涉及到组件开发的最佳实践时，REDHAWK倾向于强调自由而不是遵从。不同的组件是根据不同的用例来开发的，在REDHAWK中有许多不同的解决问题的方法。这解释了您看到的某些组件之间的一些差异。

是一个推荐的REDHAWK组件，可以作为一个标准：作为一个整体，在GitHub上发布的REDHAWK组件试图达到两个目的。它们是用于处理的有用组件的集合。而且，它们也是一套供其他人效仿的榜样。

很难选择一个组件作为最好的示例，因为每个组件都有不同的目的，并且采用了不同的方法。HardLimit组件可能是最简单的示例，因此了解开发组件的基本知识可能很有帮助。快速过滤器组件更复杂，它演示了一些更高级的概念，例如锁定和属性回调，以及重写属性验证的配置，这些属性是相互依赖的。

日志最佳实践:简而言之，在开发REDHAWK组件时，在system.out/system.error中使用日志被认为是最佳实践。

更广泛地说，在REDHAWK，伐木可能是一个困难的课题。确实没有硬性规定。通常，任何“通常”发生的事情(例如，在服务函数中接收数据包)都应该在调试或跟踪时记录下来。超出“正常”操作范围的任何内容都应作为警告记录。错误用于组件不应该出现的意外情况。在决定使用哪个级别时，可以自由地遵循log4cxx或log4j的指导原则。

一个常见的日志记录实践是在输入Q刷新时记录一个警告，这在许多组件上都可以看到。基类实现日志属性在跟踪时发生变化，因此组件开发人员不必在更高的级别上记录所有单独的属性更改本身。但是，如果他们选择这样做的话，他们可能会选择在属性回调中记录重要的属性(可能调试或信息将是一个适当的级别)。

无效属性配置:在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)，而根本不抛出无效的配置。

线程安全属性更改:属性配置期间的线程并发性非常重要，应该对所有属性进行考虑。基类在配置和查询期间使用互斥"propertySetAccess“锁定，这提供了一种简单的方法来锁定和防止任何属性同时更改为附加处理。但是，这不是推荐的行为，因为处理属性并发有不同的方法，而且在大多数情况下，所有属性配置更新的锁定都是过度的。此外，值得注意的是，当以这种方式锁定时，锁是在属性回调期间持有的，因此回调不需要重新获取锁。

对于某些属性，值在处理数据包的过程中是否发生变化可能并不重要。一个很好的例子是"upper_limit“和"lower_limit”在HardLimit中。开发人员认为这些值在处理过程中的变化并不重要，并且这个组件没有属性并发性。

对于某些属性，如快速筛选器中的"fftSize“，设计人员决定不希望该值在处理过程中更改。因此，他们有一个单独的互斥物，"filterLock_"，以防止这种情况发生。

另一个选项，而不是锁定，是创建属性的本地副本，然后在整个处理过程中使用该副本。当属性被更改为中间循环时，新值将应用到下一个服务函数中。