WebRTC源码分析-线程基础之线程基本功能

作者: ice_ly000 | 来源:发表于2019-11-13 20:03 被阅读0次

前言

如之前的总述文章所述，rtc::Thread类封装了WebRTC中线程的一般功能，比如设置线程名称，启动线程执行用户代码，线程的join，sleep，run，stop等方法；同时也提供了线程内部的消息循环，以及线程之间以同步、异步方式投递消息，同步方式在目标线程执行方法并返回结果等线程之间交互的方式；另外，每个线程均持有SocketServer类成员对象，该类实现了IO多路复用功能。

本文将针对rtc::Thread类所提供的基础线程功能来进行介绍，Thread类在rtc_base目录下的thread.h中声明，如下（删除了其他非线程基础功能的API，其他的API将于另外的文章中分析）：

class RTC_LOCKABLE Thread : public MessageQueue {
public:
  // 线程的构造，析构
  Thread();
  explicit Thread(SocketServer* ss);
  explicit Thread(std::unique_ptr<SocketServer> ss);
  Thread(SocketServer* ss, bool do_init);
  Thread(std::unique_ptr<SocketServer> ss, bool do_init);
  ~Thread() override;
  static std::unique_ptr<Thread> CreateWithSocketServer();
  static std::unique_ptr<Thread> Create();

  // 线程的名字
  const std::string& name() const { return name_; }
  bool SetName(const std::string& name, const void* obj);

  // 当前线程
  static Thread* Current();
  bool IsCurrent() const;

  // 阻塞权限
  bool SetAllowBlockingCalls(bool allow);
  static void AssertBlockingIsAllowedOnCurrentThread();

  // 休眠
  static bool SleepMs(int millis);

  // 线程的启动与停止
  bool Start(Runnable* runnable = nullptr);
  virtual void Stop();
  virtual void Run();

  // 线程的Wrap
  bool IsOwned();
  bool WrapCurrent();
  void UnwrapCurrent();

 protected:
  void SafeWrapCurrent();

  // 等待线程结束
  void Join();

 private:
#if defined(WEBRTC_WIN)
  static DWORD WINAPI PreRun(LPVOID context);
#else
  static void* PreRun(void* pv);
#endif

  bool WrapCurrentWithThreadManager(ThreadManager* thread_manager,
                                    bool need_synchronize_access);
  bool IsRunning();

  std::string name_;

#if defined(WEBRTC_POSIX)
  pthread_t thread_ = 0;
#endif
#if defined(WEBRTC_WIN)
  HANDLE thread_ = nullptr;
  DWORD thread_id_ = 0;
#endif
  bool owned_ = true;

  friend class ThreadManager;

  RTC_DISALLOW_COPY_AND_ASSIGN(Thread);
};

Thread对象的创建

创建Thread对象的构造方法有5个，如下源码所示：

// DEPRECATED.
Thread::Thread() : Thread(SocketServer::CreateDefault()) {}

Thread::Thread(SocketServer* ss) : Thread(ss, /*do_init=*/true) {}

Thread::Thread(std::unique_ptr<SocketServer> ss)
    : Thread(std::move(ss), /*do_init=*/true) {}

Thread::Thread(SocketServer* ss, bool do_init)
    : MessageQueue(ss, /*do_init=*/false) {
  SetName("Thread", this);  // default name
  if (do_init) {
    DoInit();
  }
}

Thread::Thread(std::unique_ptr<SocketServer> ss, bool do_init)
    : MessageQueue(std::move(ss), false) {
  SetName("Thread", this);  // default name
  if (do_init) {
    DoInit();
  }
}

需要注意的是：

默认构造函数Thread()被标注为DEPRECATED，原因是其对外隐藏了一个事实，即Thread对象是否与一个SocketServer对象绑定。实际上该默认构造会创建一个SocketServer对象绑定到Thread对象，而大多数的应用场景下Thread对象不需要SocketServer。因此，源码的注释中告知使用Create*的两个静态方法来创建Thread对象。
两个explicit声明的单个入参的构造函数，分别会调用含有两个入参的构造函数，唯一的区别在于入参是SocketServer*指针还是智能指针std::unique_ptr<SocketServer>类型。如果是后者那么需要使用std::move来转移SocketServer的拥有权(std::move是一个c++11的语法糖，实现了移动语义，详细的分析可以见博客C++11 std::move和std::forward)。但无论是哪个构造函数，都需要做以下三件事：
1） 构造父对象MQ。由于Thread继承于MessageQueue对象，因此首先构造MQ父对象，调用MQ的构造函数，传入SocketServer对象指针以及布尔值false。此处传入的SocketServer不允许为空，否则触发断言；此处传入布尔值false，告知MQ的构造函数 “DoInit()方法你就不要调用了，我会在外面调用的”。
2） 调用DoInit()，该方法应该在Thread构造中调用，而非在MQ的构造中调用，为什么要这么做？该方法源码如下：我们会发现该方法将MQ的初始化标志置为true，并且将自身纳入MQ管理类的管理列表中。如果DoInit在MQ构造中调用，意味着MQ构造后，Thread对象的指针已经暴露于外（被MQ管理类对象持有），此时Thread对象并未完全构建完成，其虚表vtable还未完全建立。这势必会导致Thread的对象还未构造完成时，就可能会被外部使用(在别的线程中通过MessageQueueManager访问该对象)的风险。为了规避这样的竞太条件，因此，需要给MQ的构造传入false，并在Thread构造中调用DoInit()。

void MessageQueue::DoInit() {
  if (fInitialized_) {
    return;
  }

  fInitialized_ = true;
  MessageQueueManager::Add(this);
}

3）调用SetName()方法为Thread对象命名。源码如下，需要明白的一点是，该方法的执行必须在线程启动之前，否则会触发断言。并且，由于是在线程启动之前执行，该方法仅仅是给用户层的Thread对象成员name_赋值而已，系统内核中线程相关的结构体还未建立，因此，也就无法将该名称设置到内核。只有当线程启动后，才能进一步的将name_设置到线程的内核结构体中去。一般默认名称形如"Thread 0x04EFF758"。

bool Thread::SetName(const std::string& name, const void* obj) {
  RTC_DCHECK(!IsRunning());

  name_ = name;
  if (obj) {
    // The %p specifier typically produce at most 16 hex digits, possibly with a
    // 0x prefix. But format is implementation defined, so add some margin.
    char buf[30];
    snprintf(buf, sizeof(buf), " 0x%p", obj);
    name_ += buf;
  }
  return true;
}

两个静态Create*方法来创建Thread对象，一个传入的是NullSocketServer对象，该对象不持有真正的Socket，不处理网络IO；另外一个传入PhysicalSocketServer对象，持有平台相关的Socket对象，能处理网络IO。源码如下：

std::unique_ptr<Thread> Thread::CreateWithSocketServer() {
  return std::unique_ptr<Thread>(new Thread(SocketServer::CreateDefault()));
}

std::unique_ptr<Thread> Thread::Create() {
  return std::unique_ptr<Thread>(
      new Thread(std::unique_ptr<SocketServer>(new NullSocketServer())));
}

线程的启动

线程启动相关的API为Start()，IsRunnning()，PreRun()，结构体ThreadInit，类Runable，平台相关的线程启动函数CreateThread()以及pthread_create()。

Start() 方法是WebRTC中线程启动的标准方法，算法流程如下：断言，判断线程是否已经启动-->复位底层消息循环停止标志位-->确保ThreadManager对象的创建-->赋值结构体ThreadInit->平台相关的线程启动。

bool Thread::Start(Runnable* runnable) {
  // 测试环境下的断言，当前线程必须处于非运行状态，否则触发Fatal Error
  RTC_DCHECK(!IsRunning());

  // 如果线程处于运行状态则Start返回false
  if (IsRunning())
    return false;

  // 复位消息循环stop标志位
  Restart();  // reset IsQuitting() if the thread is being restarted

  // Make sure that ThreadManager is created on the main thread before
  // we start a new thread.
  // 确保ThreadManager在主线程中构建
  ThreadManager::Instance();
  
  // 线程对象Thread不是Wrap而来
  owned_ = true;

  // 赋值结构体ThreadInit
  ThreadInit* init = new ThreadInit;
  init->thread = this;
  init->runnable = runnable;

  // 平台相关代码，Windows系统下启动线程，使用CreateThread API
#if defined(WEBRTC_WIN)
  thread_ = CreateThread(nullptr, 0, PreRun, init, 0, &thread_id_);
  if (!thread_) {
    return false;
  }
  // 类Unix系统下启动线程，使用pthread库
#elif defined(WEBRTC_POSIX)
  pthread_attr_t attr;
  pthread_attr_init(&attr);
  int error_code = pthread_create(&thread_, &attr, PreRun, init);
  if (0 != error_code) {
    RTC_LOG(LS_ERROR) << "Unable to create pthread, error " << error_code;
    thread_ = 0;
    return false;
  }
  RTC_DCHECK(thread_);
#endif

  return true;
}

RTC_DCHECK 宏在debug模式下，被定义为RTC_CHECK，起到断言的作用（具体会专门写一篇文章来分析WebRTC中的断言）；在非debug模式下，RTC_DCHECK被定义为RTC_EAT_STREAM_PARAMETERS，不论condition（ignored）是true or false，该宏定义的最后两行断言代码都不会被执行，而宏定义的第二行(true ? true : ((void)(ignored), true))是为了不让编译器报ignored未被使用的警告。

// The RTC_DCHECK macro is equivalent to RTC_CHECK except that it only generates
// code in debug builds. It does reference the condition parameter in all cases,
// though, so callers won't risk getting warnings about unused variables.
#if RTC_DCHECK_IS_ON
#define RTC_DCHECK(condition) RTC_CHECK(condition)
#else
#define RTC_DCHECK(condition) RTC_EAT_STREAM_PARAMETERS(condition)
#endif

#define RTC_EAT_STREAM_PARAMETERS(ignored)                        \
  (true ? true : ((void)(ignored), true))                         \
      ? static_cast<void>(0)                                      \
      : rtc::webrtc_checks_impl::FatalLogCall<false>("", 0, "") & \
            rtc::webrtc_checks_impl::LogStreamer<>()

IsRunning() 代码如下。在Thread类声明中，Windows环境下有两个值来表征线程，句柄类型的HWND thread_被初始化为nullptr，整数类型的DWORD thread_id_ 被初始化为0；类Unix系统中只有pthread_t thread_一个变量来表征线程，初始化为0。判断线程是否为Running状态，只要判断thread_是否为有效值即可，因为在Start()方法中启动线程时，会调用平台相关的方法给该参数赋有效值。

bool Thread::IsRunning() {
#if defined(WEBRTC_WIN)
  return thread_ != nullptr;
#elif defined(WEBRTC_POSIX)
  return thread_ != 0;
#endif
}

Restart() 是父类MQ的方法，作用是原子操作将stop_置为0，表征该MQ未停止。

void MessageQueue::Restart() {
  AtomicOps::ReleaseStore(&stop_, 0);
}

初始化ThreadManager 此处即调用ThreadManager::instance()方法，确保ThreadManager在主线程中初始化。另外owned_设置为true，表征Thread对象是常规的Start()方法启用的，而非Wrap而来。
ThreadInit 结构体用于平台相关的启动线程函数的入参，定义如下：

  struct ThreadInit {
    Thread* thread;
    Runnable* runnable;
  };

其中Runnable用来承载用户需要执行的代码，用于继承Runnable并实现Run方法即可。

class Runnable {
 public:
  virtual ~Runnable() {}
  virtual void Run(Thread* thread) = 0;
 protected:
  Runnable() {}
 private:
  RTC_DISALLOW_COPY_AND_ASSIGN(Runnable);
};

启动线程：
在Windows上调用CreateThread API来启动线程，当该方法执行成功时，将返回线程的句柄给thread_，线程的id给thread_id_，并在该线程上执行PreRun()方法，init为上述ThreadInit对象，其作为入参传递给PreRun()方法。

#if defined(WEBRTC_WIN)
  thread_ = CreateThread(nullptr, 0, PreRun, init, 0, &thread_id_);
  if (!thread_) {
    return false;
  }

在类Unix系统上，使用pthread库的pthread_create() API来启用线程，方法执行成功对pthread thread_的成员赋值，类似的将在新线程上执行PreRun()方法，并将ThreadInit结构的对象init作为其入参传入。

#elif defined(WEBRTC_POSIX)
  pthread_attr_t attr;
  pthread_attr_init(&attr);
  int error_code = pthread_create(&thread_, &attr, PreRun, init);
  if (0 != error_code) {
    RTC_LOG(LS_ERROR) << "Unable to create pthread, error " << error_code;
    thread_ = 0;
    return false;
  }
  RTC_DCHECK(thread_);
#endif

PreRun() 方法是在新启用的线程上执行的代码，不同平台下该函数声明上略有差别，实质上入参是相同的ThreadInit对象。本函数是本文最重要的地方，涉及到了ThreadManager管理Thread类的秘密，涉及到了用户代码如何在新线程上被执行，线程内部的消息循环是如何被运行起来的。
函数内部的执行逻辑写在代码注释上，特殊需要拆解的地方后续说明，源码如下：

#if defined(WEBRTC_WIN)
DWORD WINAPI Thread::PreRun(LPVOID pv) {
#else
void* Thread::PreRun(void* pv) {
#endif
  // 如前文所述，ThreadInit作为入参传给PreRun方法。
  ThreadInit* init = static_cast<ThreadInit*>(pv);
  // 将新创建的Thread对象纳入管理，与当前线程进行绑定。
  ThreadManager::Instance()->SetCurrentThread(init->thread);
  // 为线程设置名称，该方法会调用平台相关的API给线程内核结构体赋值上该线程的名称。
  rtc::SetCurrentThreadName(init->thread->name_.c_str());
 // 如果是MAC系统，通过pool对象的创建和析构来使用oc的自动释放池技术，进行内存回收。
#if defined(WEBRTC_MAC)
  ScopedAutoReleasePool pool;
#endif
  // 如果用户需要执行自己的代码，那么就会继承Runnable并实现Run方法，此时，正是执行
  // 用户代码的时刻；否则，将执行Thread的默认Run方法。
  if (init->runnable) {
    init->runnable->Run(init->thread);
  } else {
    init->thread->Run();
  }
  // 到此，线程主要的活儿已干完，以下做清理工作
  // 将线程对象与当前线程解绑
  ThreadManager::Instance()->SetCurrentThread(nullptr);
  // 释放ThreadInit对象
  delete init;
  // 返回，记得pool局部对象的释放会触发MAC系统下的自动释放池进行内存回收。
#ifdef WEBRTC_WIN
  return 0;
#else
  return nullptr;
#endif
}

上述代码需要特殊关注点在于：
1）新线程上PreRun()方法执行起来后，ThreadManager立马将当前线程与该Thread对象关联起来，纳入管理之中，当PreRun()方法要执行完毕了，又将当前线程与Thread对象解绑，毕竟该方法退出后，线程就会停止。
2）为当前线程设置名称：前文已经知道在Thread对象构造时，会给Thread的命名字段name_赋值形如"Thread 0x04EFF758"的名称，但并未调用系统相关的API给线程内核对象相关的字段赋值，因为那个时候线程还未启动，线程在系统内核中还没有相应的对象存在呢。此时，需要做这个工作。如下就是rtc::SetCurrentThreadName(init->thread->name_.c_str()) 方法的源码：

void SetCurrentThreadName(const char* name) {
#if defined(WEBRTC_WIN)
  struct {
    DWORD dwType;
    LPCSTR szName;
    DWORD dwThreadID;
    DWORD dwFlags;
  } threadname_info = {0x1000, name, static_cast<DWORD>(-1), 0};

  __try {
    ::RaiseException(0x406D1388, 0, sizeof(threadname_info) / sizeof(DWORD),
                     reinterpret_cast<ULONG_PTR*>(&threadname_info));
  } __except (EXCEPTION_EXECUTE_HANDLER) {  // NOLINT
  }
#elif defined(WEBRTC_LINUX) || defined(WEBRTC_ANDROID)
  prctl(PR_SET_NAME, reinterpret_cast<unsigned long>(name));  // NOLINT
#elif defined(WEBRTC_MAC) || defined(WEBRTC_IOS)
  pthread_setname_np(name);
#endif
}

3）作为Mac系统上的特例，使用了objc的自动释放池技术来管理内存，实际上就是通过局部变量ScopedAutoReleasePool pool的构造以及PreRun函数结束时该对象的析构来调用objc的objc_autoreleasePoolPush()和objc_autoreleasePoolPop()进行内存释放。至于其原理嘛，可以看此篇博客：自动释放池的前世今生 ---- 深入解析 Autoreleasepool

#if defined(WEBRTC_MAC)
#include "rtc_base/system/cocoa_threading.h"

extern "C" {
void* objc_autoreleasePoolPush(void);
void objc_autoreleasePoolPop(void* pool);
}

class ScopedAutoReleasePool {
 public:
  ScopedAutoReleasePool() : pool_(objc_autoreleasePoolPush()) {}
  ~ScopedAutoReleasePool() { objc_autoreleasePoolPop(pool_); }
 private:
  void* const pool_;
};
#endif

4）如果用户并不想执行自己的代码，即不给Start方法传入Runnabel对象，那么Thread对象提供了默认的Run()方法在新线程上执行，该方法源码如下。本文不展开去叙述ProcessMessages(kForever)是如何运作的，因为这属于消息循环的内容，会在下一篇文章中分析，此处只要知道，如果用户不运行自己的代码干自己的活，那么默认的方式就是启动了一个消息循环不停地在此执行。

void Thread::Run() {
  ProcessMessages(kForever);
}

bool Thread::ProcessMessages(int cmsLoop) {
  // Using ProcessMessages with a custom clock for testing and a time greater
  // than 0 doesn't work, since it's not guaranteed to advance the custom
  // clock's time, and may get stuck in an infinite loop.
  RTC_DCHECK(GetClockForTesting() == nullptr || cmsLoop == 0 ||
             cmsLoop == kForever);
  int64_t msEnd = (kForever == cmsLoop) ? 0 : TimeAfter(cmsLoop);
  int cmsNext = cmsLoop;

  while (true) {
#if defined(WEBRTC_MAC)
    ScopedAutoReleasePool pool;
#endif
    Message msg;
    if (!Get(&msg, cmsNext))
      return !IsQuitting();
    Dispatch(&msg);

    if (cmsLoop != kForever) {
      cmsNext = static_cast<int>(TimeUntil(msEnd));
      if (cmsNext < 0)
        return true;
    }
  }
}

线程的终止

停止一个线程，可以通过调用线程的Thread.Stop()方法来实施，但千万不能在当前线程上调用该方法来终止自己。MQ的Quit()方法会在介绍消息循环时来详细解释，此处作用就是停止线程消息循环。Join()方法在后面介绍，此处作用是阻塞地等待目标线程终止，因此，Stop函数一般会阻塞当前线程。

void Thread::Stop() {
  MessageQueue::Quit();
  Join();
}

线程的sleep，join以及阻塞权限

Thread类中bool blocking_calls_allowed_字段控制着在该线程是否可以运行阻塞，等待操作，比如静态方法SleepMs，线程的Join。
-SleepMs() 方法提供了线程休眠功能，方法中先对当前线程是否允许阻塞进行断言，然后在Windows上调用Windows API Sleep()方法对当前线程休眠，类Unix系统上使用nanosleep()系统调用进行休眠。

bool Thread::SleepMs(int milliseconds) {
  // 断言当前线程是否允许阻塞
  AssertBlockingIsAllowedOnCurrentThread();
 //调用不同平台下的线程休眠函数进行休眠
#if defined(WEBRTC_WIN)
  ::Sleep(milliseconds);
  return true;
#else
  // POSIX has both a usleep() and a nanosleep(), but the former is deprecated,
  // so we use nanosleep() even though it has greater precision than necessary.
  struct timespec ts;
  ts.tv_sec = milliseconds / 1000;
  ts.tv_nsec = (milliseconds % 1000) * 1000000;
  int ret = nanosleep(&ts, nullptr);
  if (ret != 0) {
    RTC_LOG_ERR(LS_WARNING) << "nanosleep() returning early";
    return false;
  }
  return true;
#endif
}

此处我们看一下这个是否允许阻塞的函数实现，该方法由NDEBUG宏来控制，意味着在debug模式下才会起作用，而非debug模式下，该函数什么也不做。在debug模式，如果当前线程关联了Thread对象，并且其Thread.blocking_calls_allowed_字段设置为false，表示不允许该线程阻塞的情况下，就会触发断言。即在此Thread所关联的线程中调用SleepMs()方法会触发断言，从而终止程序的运行。

// static
void Thread::AssertBlockingIsAllowedOnCurrentThread() {
#if !defined(NDEBUG)
  Thread* current = Thread::Current();
  RTC_DCHECK(!current || current->blocking_calls_allowed_);
#endif
}

另外，Thread也提供了一个可以设置blocking_calls_allowed_字段的方法SetAllowBlockingCalls()

bool Thread::SetAllowBlockingCalls(bool allow) {
  RTC_DCHECK(IsCurrent());
  bool previous = blocking_calls_allowed_;
  blocking_calls_allowed_ = allow;
  return previous;
}

Join()
该方法用于某个线程中等待另外一个Thread所表征的线程停止。算法流程如源码注释：

void Thread::Join() {
  // 判断等待的线程对象Thread所表征的线程是否已经停止，若已停止了，那么就不需要等待了，直接返回吧
  if (!IsRunning())
    return;
  // 断言是否是在当前线程调用自己的Join造成自己等待自己
  RTC_DCHECK(!IsCurrent());
  // 判断当前线程是否具有阻塞权限，如无，则打印警告，但是并没有进行断言
  if (Current() && !Current()->blocking_calls_allowed_) {
    RTC_LOG(LS_WARNING) << "Waiting for the thread to join, "
                        << "but blocking calls have been disallowed";
  }

  // 平台相关的实现

  // Windows平台下调用WaitForSingleObject() API进行等待
#if defined(WEBRTC_WIN)
  RTC_DCHECK(thread_ != nullptr);
  // 等待目标线程终止 
  WaitForSingleObject(thread_, INFINITE);
  // 关闭线程句柄
  CloseHandle(thread_);
  // 成员复位
  thread_ = nullptr;
  thread_id_ = 0;

  // 类Unix系统下调用pthread库的pthread_join()方法进行等待
#elif defined(WEBRTC_POSIX)
  // 等待目标线程终止 
  pthread_join(thread_, nullptr);
  // 成员复位
  thread_ = 0;
#endif
}

获取当前线程对象 && 判断是否是当前线程

获取当前线程Thread对象的方式直接复用了ThreadManager的CurrentThread()方法，若当前线程没有关联相关的Thread对象，那么返回空指针，若当前线程是创建ThreadManager对象的线程，也即主线程，那么如果主线程没有关联Thread对象，且没有定义NO_MAIN_THREAD_WRAPPING，则会给主线程Wrap一个Thread对象。

Thread* Thread::Current() {
  ThreadManager* manager = ThreadManager::Instance();
  Thread* thread = manager->CurrentThread();

#ifndef NO_MAIN_THREAD_WRAPPING
  // Only autowrap the thread which instantiated the ThreadManager.
  if (!thread && manager->IsMainThread()) {
    thread = new Thread(SocketServer::CreateDefault());
    thread->WrapCurrentWithThreadManager(manager, true);
  }
#endif
  return thread;
}

判断Thread对象是否是当前线程关联的Thread，也很简单，源码如下：

bool Thread::IsCurrent() const {
  return ThreadManager::Instance()->CurrentThread() == this;
}

线程的Wrap

Thread中Wrap相关的API有4个，如下源码所示。在WebRTC源码分析-线程基础之线程管理一文中已经解析过Wrap相关的函数，此处不再展开表述。Wrap函数主要用于如下情形：线程启动不是由标准的WebRTC启动方式实施，即不是通过调用Thread.Start()方法启动。那么，此刻线程没有与一个Thread对象相关联，那么Wrap就是干这个事，将一个线程与一个Thread对象关联起来。具体而言，有如下3件事需要做：

获取当前线程的句柄，并赋值给Thread.thread_成员；
将Thread.owned_成员设置为false，表示该线程对象是Wrap而来；
将Thread对象与当前线程关联起来，纳入ThreadManager的管理之中。

bool WrapCurrent();
void UnwrapCurrent();
void SafeWrapCurrent();
bool WrapCurrentWithThreadManager(ThreadManager* thread_manager,
                                    bool need_synchronize_access);

总结

本文阐述了rtc::Thread类所提供的基础线程功能，分别从Thread对象的创建，新线程的启动与终止，线程阻塞权限以及线程阻塞相关的函数SleepMs、Join，获取当前线程、如何判断代码是否在当前线程中执行，线程的Wrap等几个方面进行了分析。以下是需要再重点回顾的几个点：

Thread类中线程相关的功能是在封装了平台相关API的基础上实现的，在Windows系统上是通过Windows API提供，在类Unix系统上是通过pthread库提供。比如Win上创建线程CreateThread()，类Unix上相应为pthread_create()；Win上休眠Sleep()，类Unix上是nanosleep()系统调用，非pthread库功能；Win上线程join使用WaitForSingleObject()，类Unix上使用pthread库的pthread_join()；
Thread对象的构造时有个需要注意的点，那就是DoInit()方法需要Thread构造函数中被调用，否则会引发竞太条件。
Thread.Start()方法以及Thread.PreRun()方法是本文重点，是WebRTC中启动线程的标准流程。
Thread类提供了线程是否允许阻塞的权限设置，由成员Thread.blocking_calls_allowed_来控制，Thread中引发线程阻塞的函数，如SleepMs，Join，Send等都会先进行权限检查，要么打印警告日志，要么触发断言。
Thread类的Wrap函数族提供了非标准方式启动的线程纳入ThreadManager管理的额外方式。

WebRTC源码分析-线程基础之线程基本功能

前言

Thread对象的创建

线程的启动

线程的终止

线程的sleep，join以及阻塞权限

获取当前线程对象 && 判断是否是当前线程

线程的Wrap

总结

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

WebRTC

WebRTC源码分析