Fast-DDS中在ReaderListener回调中创建Writer导致的死锁问题分析

问题背景

在使用Fast-DDS的RTPS实现时，开发人员可能会遇到一个典型的死锁场景：当在ReaderListener的on_new_cache_change_added回调函数中尝试创建新的RTPSWriter时，系统会出现死锁。这种情况通常发生在需要动态创建发布者的场景中，比如实现命令-响应模式时。

死锁机制分析

这种死锁的产生源于Fast-DDS内部的多线程同步机制：

1. 消息接收线程：当接收到新数据时，会获取Reader的互斥锁(mp_mutex)来处理消息
2. Writer创建过程：在创建Writer时，需要获取RTPSParticipantImpl的endpoints_list_mutex锁
3. 匹配检查：同时，另一个线程可能正在执行端点匹配检查，此时会先获取endpoints_list_mutex的共享锁，再尝试获取Reader的mp_mutex锁

这样就形成了典型的AB-BA死锁模式：

• 线程1：持有Reader锁 → 等待Participant锁
• 线程2：持有Participant共享锁 → 等待Reader锁

Fast-DDS的设计考量

Fast-DDS的设计规范明确指出，ReaderListener的回调函数（如on_new_cache_change_added）应该仅用于处理接收到的数据变更，而不应该执行任何可能阻塞或需要获取其他锁的操作。这是因为：

1. 回调函数执行在Fast-DDS的内部线程上下文中
2. 在回调中执行复杂操作会影响整体性能
3. 创建实体是重量级操作，可能涉及多种资源的分配和初始化

解决方案建议

对于需要在收到消息后动态创建发布者的场景，推荐采用以下架构模式：

1. 异步处理机制：

   • 在回调中仅将事件放入队列
   • 使用独立线程从队列取出事件并执行实体创建

2. 预创建模式：

   • 在初始化阶段预先创建可能需要的所有发布者
   • 按需激活/停用发布者

3. 命令-响应模式优化：

   • 为每个参与者预先创建专用的响应发布者
   • 使用关联ID来匹配命令和响应

最佳实践

1. 保持回调函数简洁高效
2. 避免在回调中执行任何可能阻塞的操作
3. 实体创建等重量级操作应放在应用主线程或专用线程中执行
4. 对于动态发布需求，考虑使用预先分配+激活的模式

通过理解Fast-DDS的内部锁机制和设计原则，开发者可以避免这类死锁问题，构建更稳定高效的分布式系统。