首页 › 标签存档 › 线程池

linux c++线程池的实现

线程池的原理大家都知道,直接上代码了^_^
test.cpp

继续阅读 »

线程池(领导者-追随者,生产者-消费者等)小结

领导者/追随者模型(Leader/Followers)

这几天翻了些文章,发现对领导者/追随者模型说的比较少,下面就这个模型打个比方:

  1. 话说一个地方有一群有组织无纪律的人从事山贼这个很有前途的职业。
  2. 一般就是有一个山贼在山路口察看,其他人在林子里面睡觉。
  3. 假如发现有落单的过往客商,望风的山贼就会弄醒一个睡觉的山贼,然后自己去打劫。
  4. 醒来的山贼接替作望风的事情。
  5. 打劫的山贼搞定以后,就会去睡觉,直到被其他望风的山贼叫醒来望风为止。
  6. 有时候过往客商太多,而山贼数量不够,有些客商就能侥幸平安通过山岭(所有山贼都去打劫其他客商了)。

继续阅读 »

对libevent+多线程服务器模型的C++封装类

最近在看memcached的源码,觉得它那种libevent+多线程的服务器模型真的很不错,我将这个模型封装成一个C++类,根据我的简单测试,这个模型的效率真的很不错,欢迎大家试用。
继续阅读 »

boost高并发网络框架+线程池

boost的官方例子,有单线程的网络框架,httpserver2是线程池的。下面参照网上某人的代码修改了一点(忘了哪位大仙的代码了)
测试工具,适用stressmark,测试效果非常好, 9000个/s
继续阅读 »

高并发的epoll+线程池,业务在线程池内

epoll是linux下高并发服务器的完美方案,因为是基于事件触发的,所以比select快的不只是一个数量级。
单线程epoll,触发量可达到15000,但是加上业务后,因为大多数业务都与数据库打交道,所以就会存在阻塞的情况,这个时候就必须用多线程来提速。
业务在线程池内,这里要加锁才行。测试结果2300个/s
继续阅读 »

高并发的epoll+线程池,epoll在线程池内

epoll是linux下高并发服务器的完美方案,因为是基于事件触发的,所以比select快的不只是一个数量级。
单线程epoll,触发量可达到15000,但是加上业务后,因为大多数业务都与数据库打交道,所以就会存在阻塞的情况,这个时候就必须用多线程来提速。

继续阅读 »

高并发的epoll+多线程

epoll是linux下高并发服务器的完美方案,因为是基于事件触发的,所以比select快的不只是一个数量级。
单线程epoll,触发量可达到15000,但是加上业务后,因为大多数业务都与数据库打交道,所以就会存在阻塞的情况,这个时候就必须用多线程来提速。
下面是来一个网络连接创建一个线程处理业务,业务处理完,线程销毁。实际测试结果不是很理想,在没有业务的时候的测试结果是2000个/s
继续阅读 »

一个简单的linux线程池

线程池:简单地说,线程池 就是预先创建好一批线程,方便、快速地处理收到的业务。比起传统的到来一个任务,即时创建一个线程来处理,节省了线程的创建和回收的开销,响应更快,效率更高。
继续阅读 »

网络服务端开发小结(短连接、长连接、进程池、线程池)

平时对网络编程方面比较感兴趣,看了一些相关的资料,自己也尝试写过一些不同网络模型的服务程序。这次刚好有一个新的需求,需要开发一个转发服务器。之前开发的项目,网络通讯都是处理联机交易的,网络连接都是采用短连接,这次的服务端,采用长连接的方式。
继续阅读 »

pthread_cond

条件变量 pthread_cond, 另外一种线程间的同步机制。普通的 mutex 只允许一个线程进入临界区,就是拿到mutex这把锁的线程,而cond 允许多个线程同时进入临界区,由它来控制,在某些条件成立的时候,来唤醒其中一个等待着的线程,或者是唤醒所有等待着的线程。
继续阅读 »