linux 服务端 多线程 c++    发布于 2018-12-30   521人围观   0条评论

前言

最近在读陈硕的moduo网络库的书,记录总结一些东西。

本章内容主要介绍muduo网络库的简单使用和muduo多线程模型,以及比较muduo网络库和其他一些网络库的性能。muduo网络库的使用在此不赘述,和大部分网络库使用差不多。本章内容中让我收获比较大的是,6.6节在详解muduo多线程模型时,比较了常见的并发网络服务程序设计方案。读完这章的我有一个巨大的疑问,就是到底应该如何有效的提高并发连接数?这个问题暂时还没想的太明白

常见的并发网络服务程序设计方案

陈硕在附录A中举了三大TCP网络编程案例:echo服务器、chat聊天/聊天室以及proxy代理服务器。

方案0 单线程 accpet + read/write 最最基本的模型 

方案1 accept + fork 即每个连接均以一个进程来处理 process-per-connection

方案2 accpet + thread 即每个连接均以一个线程来处理 thread-per-connection

方案3 pre  fork 

方案4 pre threaded

方案5 单线程reactor 即单线程poll然后read/write

方案6 (过渡方案)单线程reactor + thread-per-task 依旧是单线程poll,不同的是,每个请求(不是每个链接)创建一个线程

方案7 (过渡方案)单线程reactor + work thread 依旧是单线程poll,不同的是,每个连接创建一个线程,相同链接上的请求由同一个计算线程处理,以此保证同一个连接上请求结果的顺序性,而方案6无法保证这一点。该方案的问题在于,可能还不如直接用方案2了呢。因为该方案并发连接数限制于线程数目。

方案8 单线程reactor + thread-pool 基于方案6,构造线程池,Reactor线程处理IO,计算任务交个线程。每个请求分发给计算线程池处理。该方案的每个连接上的一长串请求有乱序返回的可能,所以需要依靠id来梳理响应

方案9 reactor in threads,即one loop per thread,一个main Reactor 负责accept(2)连接,然后将连接分发到其他线程的sub Reactor上。

方案10 reactor in process,nginx内置方案。和方案9大同小异

方案11 多reactors + threa

查看更多
linux 服务端 多线程 c++    发布于 2018-12-14   67人围观   0条评论

前言

最近在读陈硕的moduo网络库的书,记录总结一些东西。

本章分析和设计一个高效的多线程日志库。

功能需求

  • 必要的需求
    • 日志级别设定
  • 非必要需求
    • 日志目的地 - 对于诊断日志来说,日志目的地即本机,因为往网络写日志消息并不可靠,诊断日志的功能之一就是诊断网络故障。
    • 日志消息格式可配置 - 可变可不变,尽量保持日志解析的方便程度,即尽量保持日志格式的不可变性
    • 日志运行时过滤器 - 控制不同组件输出不同的日志级别,可要可不要

性能需求

简而言之,就是高效,日志前端写入不会阻塞或尽量不阻塞。对日志消息前端而言,要做到低延迟、低CPU开销、少阻塞;对于日志消息后端而言,要做到足够大的吞吐量以及占用较少资源。

书中列出了几个具体指标:

  • 每秒写几千上万条日志消息时,不会带来明显的性能损失
  • 能应对一个进程产生大量日志数据的场景,例如1GB/min
  • 不阻塞正常执行的流程
  • 在多线程程序中,不造成争用

多线程异步日志

在多线程服务程序中,如果在网络IO或者业务线程中直接往磁盘写数据,写操作可能会比较耗时,直接导致请求方超时。故,在常规的实时业务处理流程中应该避免磁盘IO。

以下过程仅仅是自述理解使用,具体过程建议看书,书中写的非常详细。

muduo网络使用的双缓冲技术,即准备两块buffer,A和B,然后日志前端会兵乓式往A和B写入日志消息,日志后端会处理不在使用的那块buffer中的日志消息。在实施过程中准备了四块buffer,日志前端持有A和B,日志后端持有C和D。日志前端和后端分别持有两块Buffer Vector,V1和V2。

日志前端往A中写数据,写满时将A压入V1,用B替换A,之后继续往B中写入数据,通知日志后端处理数据。

日志后端处理过程为,等待日志前端写满A的通知,压入当前正使用的buffer到V1中,并替换日志前端的A和B为日志后端的C和D。日志后端交换V1和V2,该操作即清空日志前端的Buffer Vector,并将原Vector交于后端处理。日志后端在写入日志数据到磁盘之后,重新用A和B填满后端所需要的两块buffer。

查看更多
linux c++ 多线程    发布于 2018-12-08   242人围观   0条评论

前言

最近在读陈硕的moduo网络库的书,记录总结一些东西。

这章内容比较散,主要介绍多线程系统编程需要理解的一些知识点。看完的整个感受就是可以直接看最后的总结就行了,中间有些内容不是非常能理解的透彻。

基本线程原语

基本线程原语只需要三样东西:thread、mutex、condition。

  1. thread的创建与销毁
  2. mutex的创建、销毁、加锁、解锁
  3. condition_variable的创建、销毁、通知、广播、等待

有了这三样的东西,可以完成任何多线程编程任务。通常,不会直接使用thread和condition_variable,取而代之的是,高级的编程构建,比如线程池,比如之前提到过的CountDownLatch用于主线程和其他线程之间的同步。

C++系统库的线程安全性

这一节中的内容有些东西我还没能够完全理解,现下只记录下一些可理解的内容。以后回过头来再看看。

C++的标准库容器和std::string都不是线程安全的,只有std::allocator保证是线程安全的。一方面的原因是为了避免不必要的性能开销,另一方面的原因是单个成员函数的线程安全并不具备可组合性。

C++标准库中的绝大多数泛型算法是线程安全的,因为这些都是无状态纯函数。只要输入区间是线程安全的,那么泛型算法就是线程安全的。

 

Linux上的线程标识

linux上的线程标识不适合使用pthread_t,原因很多,详情见书。取而代之,使用的是gettid(2)系统调用,其优势书中也写的很清楚。

为了避免效率问题,使用__thread关键字做了缓存,避免每次获取线程id时都需要执行一次系统调用。

线程的创建与销毁的守则

线程的创建

线程的创建需要遵循以下几个原则:

  1. 程序库不应该在未提前告知的情况下创建自己的背景线程
  2. 尽量用相同的方式创建线程
  3. 在进入main()函数之前不应该启动线程
  4. 程序中线程的创建最好能在初始化阶段全部完成,不要为了每个计算任务或者每个网络连接去实时创建线程

以上四点都比较直观,也很容器理解。

针对第一点,如果程序库需要使用背景线程,那么最好让使用者在初始化库时传入线程池或者event loop对象,这样做是为了方便统筹线程的数目和用途,避免低优先级程序的任务独占某个线程。如果程序库在未告知的情况下使用了额外线程,那么会使得我们在规划线程资源的时候漏算一部分,甚至可能使得关键任务的计算资源无法达到性能指标。

针对第二点,统一的方

查看更多
c++ linux 多线程    发布于 2018-12-01   300人围观   0条评论

前言

最近在读陈硕的moduo网络库的书,记录总结一些东西。

读完本章,最大的收获是无论是CPU密集型还是IO密集型,多线程相对于多进程都没有绝对的性能优势。多线程相对于单线程的真正优势是降低平均响应时间。此外,进一步了解最常用的Reactor模型和多线程的一些细节上的东西。

多线程的主要适用场景是计算与IO叠加进行的场景,多进程的主要适用场景是各项任务较为独立的场景。没有银弹,选择多进程还是多线程,需要根据针对不同的场景做不同的设计。

进程与线程

进程与线程之间的区别是老生常谈的知识点,也是我们在设计一个系统时首先要考虑的点。今年阅读和编写了很多多进程和多线程的代码,也看了很多多线程和多进程编程的文章。个人对这两个东西的理解有了很大的提升。下面叙述最近醒悟的几个点:

① 之前我一直以为UI应用就应该使用多线程模型,其实大错特错。

的确,UI应用一般会有一个UI线程用来事件循环界面上的事件,但是其他脏活累活既可以扔给其他线程、也可以扔给其他进程,前者需要考虑线程之间的逻辑关系,而后者考虑的是进程之间的逻辑关系。

② 如果某个多任务应用需要适应单核环境,那么这时候应该使用状态机还是多线程?

单核环境下,状态机的好处是手动调度可以获取更好的性能,但是协调各个任务之间的关系略显蛋疼。相对来说,多线程更加直观,但是线程在单核上的上下文切换以及同步就比较糟蹋性能了。所以说,具体问题具体分析,特殊情况特殊对待,设计系统这种东西,要看场景,要讲经验。

③ 多核环境下呢?

多核环境下,状态机和多线程,当然首选多线程,这样可以更好的发挥多核处理器的性能。那么既然是多核了,直接上多进程来替代多线程岂不更好?问题来了,单核环境下多线程没有状态机高效,多核环境下多线程没有多进程高效,那么多线程的真正优势是什么?

③ 多线程的真正优势

多线程相对于单进程的真正优势是降低响应时间,提高响应速度。但是,多线程与多进程之间的选择往往视情况而定,这里引用书中原话“在其他条件相同的情况下,可以根据工作集合(work set)的大小来取舍,工作集指服务程序响应一次请求所访问的内存大小。如果工作集较大,那么就用多线程,避免CPU cache换入换出,影响性能;否则,就用单线程多进程,享受单线程编程的遍历。

即,多线程和多进程的共享内存同步和通信都比较麻烦,但是如果工作集较大,则多线程避免cpu cached换入换出。但是如果用不了

查看更多
c++ 多线程    发布于 2018-11-10   412人围观   0条评论

前言

最近在读陈硕的moduo网络库的书,记录总结一些东西。在并发编程中,有两种基本模型,一种是message passing,另外一种是Shared memory。这一章主要讲述shared memory模型下线程同步需要注意的一些问题。作者陈硕推荐尽可能使用message passing,因为其更容易保证程序的正确性,并且可以移植到分布式系统中,扩容性更强。但是多线程编程仍然需要程序员了解shared memory情形,以备不时之需。

本章题名为“线程同步精要”,又在文章开头提到并发编程的两种基本模型,私以为,线程同步精要指的单单是shared memory,只有线程间共享的资源,才需要采取同步措施来保证资源的正确访问。本章作者分享的是他个人在线程同步方面的经验与心得。

 

线程同步的四项原则

文中按照重要性先后列出线程同步的四项原则

  1. 首要原则是尽量最低限度地共享对象,减少需要同步的场合。一个对象能不暴露给别的线程就不要暴露;如果要暴露,优先考虑immutable对象;实在不行才暴露可修改的对象,并用同步措施来充分的保护它。
  2. 其次是使用高级的并发编程构件,如TaskQueue、Producer-Consumer Queue、CountDownLatch等等。
  3. 最后不得已必须使用底层同步原语(primitives)时,只用非递归的互斥器和条件变量,慎用读写锁,不要用信号量。
  4. 除了使用atomic整数之外,不自己编写lock-free代码,也不要用“内核级”同步原语。不凭空猜测“哪种做法性能更好”,比如“spin lock vs. 
原则第一条就可以看出作者极力不推荐共享内存,笔者个人的经验是,共享资源给程序的编写和维护带来许多不便,与作者同感。
原则第二条是在解释,如果线程间需要共享某些资源,则最好采用高级组件避免繁复的与底层原语打交道的编程过程。个人在这里的经验是,采用高级组件可以提高开发效率。
原则第三条是若不得不使用底层原语,则最好只使用非递归的互斥器和条件变量,其他的不要用,文中针对第三点作了大篇幅的解释。

原则第三条

互斥器

互斥器,很简单,就是RAII收发,常见的MutexLock和MutexLockGuard手法,MutexLock负责锁的创建和销毁以及判断是否被锁,MutexLockGuard负责加锁解锁(即临界区的进入和退出)。

作者推荐使用非递归锁,因为同一个线程中多次对非递

查看更多