WebRTC学习进阶之路 --- 十五、源码分析之WebRTC中的线程详解-MessageQueueManager&MessageQueue&Message&MessageHandler

WebRTC学习进阶之路系列总目录：https://blog.csdn.net/xiaomucgwlmx/article/details/103204274

本文将介绍消息的管理类(MessageQueueManager)、消息循环中的消息(Message)、消息中的数据(MessageData)、消息队列(MessageQueue)以及处理消息的Handler(MessageHandler)的基本内容。

除了MessageHandler均位于rtc_base/message_queue.h和rtc_base/message_queue.cc中，MessageHandler相关的类位于rtc_base/message_handler.h中，下边注意分析。

一、MessageQueueManager

顾名思义，与ThreadManager和Thread的关系类似，MessageQueueManager类是为了对MessageQueue进行管理而存在，源码头文件如下：

class RTC_EXPORT MessageQueueManager {
 public:
  static void Add(MessageQueue* message_queue);
  static void Remove(MessageQueue* message_queue);
  static void Clear(MessageHandler* handler);

  // TODO(nisse): Delete alias, as soon as downstream code is updated.
  static void ProcessAllMessageQueues() { ProcessAllMessageQueuesForTesting(); }

  // For testing purposes, for use with a simulated clock.
  // Ensures that all message queues have processed delayed messages
  // up until the current point in time.
  static void ProcessAllMessageQueuesForTesting();

 private:
  static MessageQueueManager* Instance();

  MessageQueueManager();
  ~MessageQueueManager();

  void AddInternal(MessageQueue* message_queue);
  void RemoveInternal(MessageQueue* message_queue);
  void ClearInternal(MessageHandler* handler);
  void ProcessAllMessageQueuesInternal();

  // This list contains all live MessageQueues.
  std::vector<MessageQueue*> message_queues_ RTC_GUARDED_BY(crit_);

  // Methods that don't modify the list of message queues may be called in a
  // re-entrant fashion. "processing_" keeps track of the depth of re-entrant
  // calls.
  CriticalSection crit_;
  size_t processing_ RTC_GUARDED_BY(crit_);
};

 

同样的MessageQueueManager也采用单例Instance()的方式构造，和上一篇ThreadManager的方式一样，这里不做赘述，下边我们来看下几个核心方法。

1，数据的添加(Add)、删除(Remove)与清空(Clear)

void MessageQueueManager::Add(MessageQueue* message_queue) {
  return Instance()->AddInternal(message_queue);
}
void MessageQueueManager::AddInternal(MessageQueue* message_queue) {
  CritScope cs(&crit_);
  // Prevent changes while the list of message queues is processed.
  RTC_DCHECK_EQ(processing_, 0);
  message_queues_.push_back(message_queue);
}

void MessageQueueManager::Remove(MessageQueue* message_queue) {
  return Instance()->RemoveInternal(message_queue);
}
void MessageQueueManager::RemoveInternal(MessageQueue* message_queue) {
  {
    CritScope cs(&crit_);
    // Prevent changes while the list of message queues is processed.
    RTC_DCHECK_EQ(processing_, 0);
    std::vector<MessageQueue*>::iterator iter;
    iter = absl::c_find(message_queues_, message_queue);
    if (iter != message_queues_.end()) {
      message_queues_.erase(iter);
    }
  }
}

void MessageQueueManager::Clear(MessageHandler* handler) {
  return Instance()->ClearInternal(handler);
}
void MessageQueueManager::ClearInternal(MessageHandler* handler) {
  // Deleted objects may cause re-entrant calls to ClearInternal. This is
  // allowed as the list of message queues does not change while queues are
  // cleared.
  MarkProcessingCritScope cs(&crit_, &processing_);
  for (MessageQueue* queue : message_queues_) {
    queue->Clear(handler);
  }
}

• crit_：临界区类CriticalSection的对象，该成员保证多线程环境下访问安全，正如上面两个函数所示，函数开头创建CritScope cs(&crit_); 在cs的构造函数中调用crit_->Enter()表示进入临界区，相当于上锁。利用函数结束后cs对象的析构中调用crit_->Leave()表示离开临界区，相当于解锁。
  然后我们要知道CriticalSection是可重入的，也即一个线程上调用cs_->Enter()上锁之后，在释放锁之前，同一个线程可以反复调用cs_->Enter()而不会阻塞，因此被称为“可重入锁”。同一个线程上锁一次，processing_就增1，记录上锁次数，只要processing_不为0，表示我正在Clear操作或者后文的Process*方法，这两个方法不会改变Vector列表，如上代码及注释所示ClearInternal的操作是“删除对象可能导致重新进入对ClearInternal的调用。 这是允许的，因为清除队列时消息队列列表不会更改。”，因此，可以在解锁之前，重入进行反复操作，但是不允许Add和Remove操作，因为其会改变Vector，这就是为什么Add和Remove函数中既加锁了，还要断言processing_必须为0。
• processing_ ：声明为 size_t processing_ RTC_GUARDED_BY(crit_); Add与Remove函数中执行了RTC_DCHECK_EQ(processing_, 0)断言，必须确保processing_ 为0。当processing_不为0时，要么在执行Clear()方法，要么在执行ProcessAllMessageQueues()。

看了这段时间源码，我们发现大部分方法的具体实现都是私有的*Internal*(...)作为内部实现，比较清晰。

2，消息的具体处理

void MessageQueueManager::ProcessAllMessageQueuesInternal() {
  // This works by posting a delayed message at the current time and waiting
  // for it to be dispatched on all queues, which will ensure that all messages
  // that came before it were also dispatched.
  volatile int queues_not_done = 0;

  // This class is used so that whether the posted message is processed, or the
  // message queue is simply cleared, queues_not_done gets decremented.
  class ScopedIncrement : public MessageData {
   public:
    ScopedIncrement(volatile int* value) : value_(value) {
      AtomicOps::Increment(value_);
    }
    ~ScopedIncrement() override { AtomicOps::Decrement(value_); }

   private:
    volatile int* value_;
  };

  {
    MarkProcessingCritScope cs(&crit_, &processing_);
    for (MessageQueue* queue : message_queues_) {
      if (!queue->IsProcessingMessagesForTesting()) {
        // If the queue is not processing messages, it can
        // be ignored. If we tried to post a message to it, it would be dropped
        // or ignored.
        continue;
      }
      queue->PostDelayed(RTC_FROM_HERE, 0, nullptr, MQID_DISPOSE,
                         new ScopedIncrement(&queues_not_done));
    }
  }

  rtc::Thread* current = rtc::Thread::Current();
  // Note: One of the message queues may have been on this thread, which is
  // why we can't synchronously wait for queues_not_done to go to 0; we need
  // to process messages as well.
  while (AtomicOps::AcquireLoad(&queues_not_done) > 0) {
    if (current) {
      current->ProcessMessages(0);
    }
  }
}

• 线程调用消息处理时会遍历所有的message_queues_，然后向每个MessageQueue中投递一个消息ID为MQID_DISPOSE的延迟消息，MessageData数据为ScopedIncrement对象，ScopedIncrement的构造中调用系统API将queues_not_done原子性自增1(原子性加减https://baike.baidu.com/item/InterLockedIncrement/302345?fr=aladdin)，表示该消息队列中有消息没有被处理，而该延迟消息时间为0，那么该延迟消息将进入MessageQueue的延迟消息队列的队首(因为MQ的延迟消息队列是以延迟时间排序的优先级队列)。
• 获取调用该方法的线程所关联的Thread对象，并通过Thread对象