网上已经有网友duguguiyu针对Chrome的线程体系做了很专业的描述了,应该说从原理上已经很完整了。本文主要在网友的基础上从代码实现的角度上进行一些补充和分析。
提到线程,我想大家关注的无非几点:线程的消息循环机制、多线程同步机制,线程间通信机制。
本文也是从大家关注的几点来重点描述。
在Chrome的代码中,与线程相关的文件主要在/base/base.vcproj中。
主要包含了以下相关文件:
task.h 线程执行的任何任务都是以task对象方式传递,有不同类型的task。
message_pump.h
message_pump_default.h
message_pump_default.cc
message_pump_win.h
message_pump_win.cc 消息泵类,消息调度,分发处理。
message_loop.h
message_loop.cc 消息循环机制,基本上每一个线程都有自己的消息循环,接收来自其他线程、UI甚至系统的消息。
thread.h
thread.cc 线程虚类类。Thread类在操作系统上层做了抽象,本身与平台无关
platform_thread.h
platform_thread_win.cc Windows平台下线程的相关方法。在Windows平台下是CreateThread方法。
thread_local.h
thread_local.cc
thread_local_storage.h
thread_local_storage_win.cc 线程本地存储机制的实现(TLS)
其他还有一些辅助类,可以不用太关注,比如智能指针、一些简单的工具类等。我们重点分析上述的代码。
总体来说,Chrome的线程实现,主要运用了Command、Bridge和Observer三种模式。
我们观看一下Thread.h中对Thread的定义
//平台相关的线程函数,不同平台有不同的实现机制。
class PlatformThread {
Thread是一个与平台无关的线程抽象类。真正线程创建的相关函数在PlatformThread类中处理,而PlatformThread类的实现根据不同的操作系统又有不同的实现。在Windows平台下实现的是
platform_thread_win.cc。
我们跟踪一下线程函数的执行流程:
下面是platform_thread_win.cc中的实现:
1. *thread_handle = CreateThread(
NULL, stack_size, ThreadFunc, delegate, flags, NULL);
ThreadFunc是线程函数,线程的执行体从此开始。
2. ThreadFunc函数实际调用的是delegate->ThreadMain();函数,由于Thread类实现了PlatformThread:Delegate代理类, 因此实际上调用的是Thread类的ThreadMain函数。
3.观察Thread类的ThreadMain函数实现,ThreadMain函数实际启动了消息循环MessageLoop,MessageLoop类接收不同的任务,并进行处理。
void Thread::ThreadMain() {
// 创建消息循环.
MessageLoop message_loop(startup_data_->options.message_loop_type);
thread_id_ = PlatformThread::CurrentId();
PlatformThread::SetName(name_.c_str());
message_loop.set_thread_name(name_);
message_loop_ = &message_loop;
//进一步初始化
Init();
//设置启动完毕信号量信号
startup_data_->event.Signal();
//消息循环开始启动,线程阻塞于此
message_loop.Run();
//线程结束,收尾工作
CleanUp();
DCHECK(GetThreadWasQuitProperly());
message_loop_ = NULL;
thread_id_ = 0;
}
4.我们进一步跟踪一下MessageLoop的Run函数实现。可以发现实际上真正的线程调度工作是MessagePump类来实现的。
5.由于MessagePump类是一个虚类,其根据不同的线程类型有不同的调度方法,我们先看看MessagePumpDefault类怎么实现的。
void MessagePumpDefault::Run(Delegate* delegate) {
DCHECK(keep_running_) << "Quit must have been called outside of Run!";
for (;;) {
ScopedNSAutoreleasePool autorelease_pool;
bool did_work = delegate->DoWork();
if (!keep_running_)
break;
did_work |= delegate->DoDelayedWork(&delayed_work_time_);
if (!keep_running_)
break;
if (did_work)
continue;
did_work = delegate->DoIdleWork();
if (!keep_running_)
break;
if (did_work)
continue;
if (delayed_work_time_.is_null()) {
event_.Wait();
} else {
TimeDelta delay = delayed_work_time_ - Time::Now();
if (delay > TimeDelta()) {
event_.TimedWait(delay);
} else {
// It looks like delayed_work_time_ indicates a time in the past, so we
// need to call DoDelayedWork now.
delayed_work_time_ = Time();
}
}
// Since event_ is auto-reset, we don't need to do anything special here
// other than service each delegate method.
}
keep_running_ = true;
}
这个函数的实现有一些灵巧的调度算法包含在里面,我们将在第二节的消息循环中去详细讲解。
从上面的分析来看,Thread类并不真正的实现任何业务功能,仅仅实现了任务的调度,线程的启动、停止等功能,线程需要执行的工作都是由用户来提交的。这个任务就是Task类的提交的,这里用到了典型的Command模式。
下面的图是设计模式中Command模式的典型结构图:
把一个请求封装成一个对象,从而使你可以用不同的请求对客户进行参数化,对请求排队或者记录请求日志,以及支持可撤销的操作。
引用网友Venus的话。
Command模式
Command 模式,是一种看上去很酷的模式,传统的面向对象编程,我们封装的往往都是数据,在Command模式下,我们希望封装的是行为。这件事在函数式编程中很正 常,封装一个函数作为参数,传来传去,稀疏平常的事儿;但在面向对象的编程中,我们需要通过继承、模板、函数指针等手法,才能将其实现。。。
应用Command模式,我们是期望这个行为能到一个不同于它出生的环境中去执行,简而言之,这是一种想生不想养的行为。我们做Undo/Redo的时 候,会把在任一一个环境中创建的Command,放到一个队列环境中去,供统一的调度;在Chrome中,也是如此,我们在一个线程环境中创建了 Task,却把它放到别的线程中去执行,这种寄居蟹似的生活方式,在很多场合都是有用武之地的。。。
对应在Chrome中线程的实现Task实现了Command模式中的Command接口,而类似CancelableTask,DeleteTask,ReleaseTask等类实现了COncreteCommand类。MessageLoop类相当于是一个Receiver,负责接收各种任务,并进行处理。
举一个例子:
这种设计方法,把线程的调度和实际的任务进行了分离,减少了模块之间的耦合性。同时具有:
1. 与我们传统的实现方式不同,抛弃了Callback函数方式,先注册,以后调用。采用Task方式,具有更多的自由度。
2. 一个Task对象和原先的请求发出者(Invoker)可以有不同的生命期。换言之,原先的请求发出者(Invoker)可能已经不在了,而Task对象本身仍然是活动的。
消息循环机制
未完待续