WebRTC源码分析-线程基础之MessageQueueManager
目录
前言
MessageQueueManager的构造
MessageQueue的添加与移除
清理
处理所有MQ中的消息
总结
前言
正如其名，MessageQueueManager类(后续简写为MQM)提供了MessageQueue(简写为MQ)的管理功能。在之前的文章中已经分析过，MQ在构建时会调用MQ.DoInit()方法，该方法将MQ添加到MQM的内部std::Vector
MQM类的声明和定义分别在rtc_base/message_queue.h以及rtc_base/message_queue.cc中，其定义如下所示
// MessageQueueManager does cleanup of of message queues
class 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 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的构造
MessageQueueManager的构造方式与ThreadManager一样，都是单例模式，都是非安全的。之前分析过ThreadManager为什么能够安全的构造，MessageQueueManager原理一样，并且MessageQueueManager对象的创建先于第一个MessageQueue对象。
MessageQueueManager* MessageQueueManager::Instance() {
static MessageQueueManager* const instance = new MessageQueueManager;
return instance;
}
MessageQueueManager::MessageQueueManager() : processing_(0) {}
MessageQueueManager::~MessageQueueManager() {}
MessageQueue的添加与移除
MessageQueueManager提供了Add与Remove的静态函数来往单例的管理类中添加和删除MQ，具体如下源码所示：
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::iterator iter;
iter = std::find(message_queues_.begin(), message_queues_.end(),
message_queue);
if (iter != message_queues_.end()) {
message_queues_.erase(iter);
}
}
}
添加和删除方法对外都是以静态方法提供，通过调用MQM的单实例的对应的私有方法来实现往向量Vector中添加和删除MQ，需要说明的注意点有以下几个：
1）成员crit_是临界区类CriticalSection的对象，该成员保证多线程环境下MQM.message_queues_以及MQM.processing_访问安全，正如上面两个函数所示，函数开头创建CritScope cs(&crit_); 在cs的构造函数中调用crit_->Enter()表示进入临界区，相当于上锁。利用函数结束后cs对象的析构中调用crit_->Leave()表示离开临界区，相当于解锁。
2）存储MQ的向量声明为：std::vector
其中RTC_GUARDED_BY宏在clang编译器下展开为attribute(guarded_by(crit_))，指示编译器在编译过程中检查代码中所有访问message_queues_的各个路径上是否都先获取了锁crit_，如果没有就会在编译过程中产生错误或者警告。而对于其他编译器，该宏不起任何作用，意味着不会在编译期进行检查。详见 Thread Safety Analysis。
3）成员processing_ 声明为： size_t processing_ RTC_GUARDED_BY(crit_); Add与Remove函数中执行了RTC_DCHECK_EQ(processing_, 0)断言，必须确保processing_ 为0。当processing_不为0时，要么在执行MQM的Clear()方法，要么在执行ProcessAllMessageQueues()，这些操作此时，是不允许往MQM添加MQ或者删除MQ这种会改变Vector列表的操作，因为前面的两个函数一般都会要遍历Vector。思考一点，不是已经上锁保证线程安全了嘛，为啥还要保证processing_为0呢？继续往下看吧~~
清理
与Add和Remove方式一摸一样，Clear函数也是以静态方法的形式对外提供。Clear函数的作用是从MQM所管理的所有MQ中删除与入参MessageHandler* handler匹配消息。具体而言就是遍历MQM中的MQ，然后调用MQ本身的Clear()方法，这个方法比较冗长，此处就不展开叙述，将会在介绍MQ的文章中详细描述。
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);
}
}
另外很重要的一点，该方法并没有使用前文所述的CritScope cs(&crit_)来实现线程安全，而是使用了一个新的类MarkProcessingCritScope cs(&crit_, &processing_)，有什么神奇的地方？且看源码：
class RTC_SCOPED_LOCKABLE MarkProcessingCritScope {
public:
MarkProcessingCritScope(const CriticalSection* cs, size_t* processing)
RTC_EXCLUSIVE_LOCK_FUNCTION(cs)
: cs_(cs), processing_(processing) {
cs_->Enter();
*processing_ += 1;
}
~MarkProcessingCritScope() RTC_UNLOCK_FUNCTION() {
*processing_ -= 1;
cs_->Leave();
}
private:
const CriticalSection* const cs_;
size_t* processing_;
RTC_DISALLOW_COPY_AND_ASSIGN(MarkProcessingCritScope);
};
首先要知道CriticalSection是可重入的，也即一个线程上调用cs_->Enter()上锁之后，在释放锁之前，同一个线程可以反复调用cs_->Enter()而不会阻塞，因此被称为“可重入锁”。同一个线程上锁一次，processing_就增1，记录上锁次数，只要processing_不为0，表示我正在Clear操作或者后文的Process*方法，这两个方法不会改变MQM中Vector列表，因此，可以在解锁之前，重入进行反复操作，但是不允许Add和Remove操作，因为其会改变Vector，这就是为什么Add和Remove函数中既加锁了，还要断言processing_必须为0，否则代码就是写得有Bug了。
处理所有MQ中的消息
这个方法目前还没有完全的理解，首先说下我自己的分析。
- 方法如其名，目标在于使得MQM中管理的MQ中的消息得到处理。
- 当某个线程调用该方法时，会遍历所有的MQ，然后向MQ中投递一个消息ID为MQID_DISPOSE的延迟消息，其消息数据为ScopedIncrement对象，ScopedIncrement的构造中将queues_not_done原子性自增1，表示该消息队列中有消息没有被处理，而该延迟消息时间为0，那么该延迟消息将进入MQ的延迟消息队列的队首(因为MQ的延迟消息队列是以延迟时间排序的优先级队列)。记住，所有的MQ中都会投递一个这样的消息。
- 方法后续就是获取调用该方法的线程所关联的Thread对象，并通过Thread对象的ProcessMessages方法不断的从当前线程的MQ中取出消息进行处理，直到queues_not_done为0，此时，之前投递到消息循环中的MQID_DISPOSE类别的消息得到处理，因为该消息在消息循环中被取出后，消息数据ScopedIncrement对象会被直接delete，从而ScopedIncrement析构完成queues_not_done原子性自减1。此时，表征着该消息循环中的所有即时消息都得到了处理。
- 最大的疑惑就是，所有的MQ中都放入了一个MQID_DISPOSE类别的延迟消息，调用该方法的线程会如上所述的方式阻塞地将所有即时消息处理掉，而没有主动调用该方法的线程是如何保证该方法的目标得以实现的，即，使得所有MQ的即时消息都能同步的立马处理？毕竟，对于其他的MQ此处也仅仅是投递了一个MQID_DISPOSE类别的延迟消息而已。
static void ProcessAllMessageQueues() { ProcessAllMessageQueuesForTesting(); }
void MessageQueueManager::ProcessAllMessageQueuesForTesting() {
return Instance()->ProcessAllMessageQueuesInternal();
}
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);
}
}
}
总结
- MessageQueueManager是管理MessageQueue的类，与ThreadManager管理Thread的方式是不同的。MQM内部的向量成员std::Vector
- MQM对外提供了所有方法都是静态方法，这些静态方法均是调用MQM单实例的私有的同名函数来实现添加，删除MQ，清除所有MQ中含有某个MessageHandler的所有消息，处理所有MQ中的消息。
- 为了线程安全，MQM中的所有操作都由CriticalSection crit_来提供上锁的操作，该对象对外暴露的是Windows上临界区概念的API，其提供了Enter()，Leave()等进出临界区的方法。CriticalSection跨平台是如何实现的？请看WebRTC源码分析-线程安全之CriticalSection。 实践上，在需要上锁的地方创建一个CritScope cs(&crit_)局部对象，这个cs局部对象的构造函数中调用crit_->Enter()进行上锁，利用局部对象在{}之后的析构中调用crit_->Leave()来解锁。
- 为了给MQM的Clear和Process* 方法提供可重入访问方法，又需要与Add和Remove方法互斥，因此，在Clear和Procees* 方法中使用MarkProcessingCritScope来提供上锁计数processing_，Add和Remove中断言processing_来确保操作安全。
- 关于Procees* 如何使得所有线程的消息得到处理的疑惑，可能是局限于MQM类的分析无法全局看到实现机制，当前只知道调用该方法的线程是如何达到处理所有即时消息的。而相关的方法本文没有展开来说，会在介绍Thread和MQ的文章中详细阐述。如果谁理解了该函数如何使得其他线程处理所有即时消息的机制，希望留言。