【zz】webrtc线程模型

#- 转载 作者
webrtc的base的 thread&＃xff0c;是我见过的封装最帅的c&＃43;&＃43;线程库&＃xff0c;根据比qt的还好用,发个例子给你

using namespace webrtc;
using namespace rtc;
//std::cout<<"Thread::Current()&＃xff1a;" <GetId();
//Thread::Current()->Start(); 不能调用start&＃xff0c;因为不是我创建的&＃xff0c;他已经开始了//Thread::Current()->Run(); //阻塞当前线程进入线程循环Thread * thread &＃61; new Thread();
//MyRunnable run;
//thread->Start(&run);//可以带一个Runnable参数运行,运行完就结束&＃xff0c;否则运行Thread::Run进入消息循环
thread->Start();
//std::cout <<"Thread::Invoke()&＃xff1a;"<Invoke(RTC_FROM_HERE, &task)<<" at " <GetId() <thread->Post(RTC_FROM_HERE, Bind(task2));//将最常用的
auto handler&＃61; new MessageClient;
//thread->PostAt(RTC_FROM_HERE, (int64_t)3000,handler);
//thread->PostDelayed(RTC_FROM_HERE, (int64_t)5000, handler);
//thread->Stop();

Thread * thread2 &＃61; new Thread();
thread2->Start();
thread2->Post(RTC_FROM_HERE, Bind(task2));//将最常用的
//thread2->Invoke() 非常有用&＃xff0c;在任何地方可以指定我的代码运行在某个线程


//api下的proxy机制&＃xff0c;实际上就是设置要执行的线程&＃xff0c;然后加锁等待线程执行结果。这是我设计对外接口可以在任何线程调用而不出错的常用方法

//base的asyncinvoker与proxy类似的机制。
有ios的gdc&＃xff0c;android的handler异曲同工

因为编写复杂稳定的多线程C&＃43;&＃43;项目实在太难&＃xff0c;所以一个好的跨平台C&＃43;&＃43;基础库是我最求的目标,目前比较欣赏的项目有&＃xff1a;

Boost:大而全&＃xff0c;缺少一些可以直接上手的东西如线程消息队列&＃xff0c;智能指针并非线程安全。 QT core&＃xff1a;非常好 C&＃43;&＃43;11&＃xff1a;也需要线程消息队列&＃xff0c;线程安全智能指针。 chromium的base库&＃xff1a;太大了 当我看到webrtc的base时&＃xff0c;非常惊讶的发现它正是我想要的,特点&＃xff1a;

小&＃xff1a;只有几M 纯&＃xff1a;基于c&＃43;&＃43;标准库和各操作系统sdk 跨平台 对智能指针、线程、socket封装非常好。 不断更新&＃xff08;需要一直跟踪官方代码&＃xff09; 移植出来单独使用&＃xff0c;方案有三&＃xff1a;

把源码拷贝出来用通用的编译工具&＃xff08;makefile&＃xff0c;cmake&＃xff0c;qmake&＃xff09;管理。&＃xff08;makefile较复杂&＃xff0c;cmake简单&＃xff0c;qmake最简单&＃xff09; 把源码拷贝出来用基于自带的gn管理 在webrtc项目里面编译和合并需要的静态库和pdb

因为google官方说了&＃xff1a;引用计数&＃43;引用计数的智能化&＃xff08;scoped_ref_ptr&＃xff09;&＃43;弱引用就可以解决问题。 shared_ptr不是线程安全的&＃xff0c;因为shared_ptr有两个成员&＃xff1a;引用计数&＃xff0c;和源对象指针。没办法对两个成员同时实现原子操作。 但unique_ptr是个好东西

智能指针的使用&＃xff1a;

不用再使用delete。
尽量使用unique_ptr。
多个线程读写同一个 shared_ptr 对象&＃xff0c;那么需要加锁。
shared_ptr 和weak_ptr配合解决循环引用的问题。
weak_ptr必须&＃xff0c;oc&＃xff0c;swift的ViewControler和控件都是weak关系

内存管理模型的三种级别&＃xff1a; 1 手动内存管理(c/c&＃43;&＃43;的malloc与free&＃xff0c;new与delete)&＃xff1a;容易出错。 2 自动内存管理&＃xff08;oc的arc&＃xff0c;c&＃43;&＃43;的智能指针&＃xff0c;scoped_ptr&＃xff09;&＃xff1a;存在循环引用问题&＃xff0c;通过程序员自己管理强弱引用关系解决。 3 垃圾回收机制&＃xff08;如java,python&＃xff09;&＃xff1a;后台GC降低了程序效率&＃xff0c;好的程序员仍然好考虑java的强引用[表情]引用/软引用/

3 线程模型 1 生产者消费模型&＃xff08;mutex&＃xff0c;condition&＃xff09;&＃xff1a;最最常用的模型。 2 线程池模型&＃xff1a;解决大量请求分配太多线程的问题。比如一个android和ios的app&＃xff0c;http请求会很多很多。 3 (着重强调&＃xff09;串行模型&＃xff1a;ios有GCD(Grand Central Dispatch&＃xff0c;global queue是线程池&＃xff09;&＃xff0c;android有looper&＃xff0c; win32有PostMessage&＃xff0c;boost有strand 读写锁&＃xff1a;特别只有写才会不安全的情况。 再结合其他的手段会让程序简洁优美易读&＃xff1a;java的handler&＃xff0c;oc的delegate和block、swift的闭包&＃xff0c;mvc模式 &＃xff0c;c&＃43;&＃43;的function/bind/lambda&＃xff0c;python和Javascript的function

而串行模型就成了解决这类多线程问题的首选&＃xff0c;就是线程消息模型。 在android 系统里面&＃xff0c;无数这样的例子。

模块处理线程
Call构造方法中创建module_process_thread与pacer_thread两个ProcessThread.接着为module_process_thread注册CallStats, ReceiveSideCongestionController, SendSideCongestionController模块,为pacer_thread注册PacedSender, RemoteBitrateEstimator模块.

Call::CreateVideoSendStream创建VideoSendStream时,将module_process_thread做构造参数传入,调用RegisterProcessThread方法,注册所有的rtc_rtcp模块到module_process_thread线程.同样的为VideoReceiveStream中设置.