用多进程解决生产着消费者问题之后，再尝试多线程方法，才知道多线程多么地方便。多线程方案的易用性，一方面得益于强大的条件变量。赞，太好用了！
互斥量实际上相当于二元信号量，它是纯天然适合生产者消费者问题的解决方案，使用互斥量可以很好地描述生产者或者消费者独占缓冲区的特点。
不过互斥量的能力也仅此而已，如果需要在使用线程方案时提供更复杂的逻辑，则需要配合使用条件变量。生产者要求在缓冲区不满的情况下才能生产，我用 notFull 条件变量表示这种情况；消费者要求在缓冲区不空的情况下才能消费，我用 notEmpty 条件描述这种情况。
继续阅读 »
boost的官方例子，有单线程的网络框架，httpserver2是线程池的。下面参照网上某人的代码修改了一点（忘了哪位大仙的代码了）
测试工具，适用stressmark，测试效果非常好， 9000个/s
继续阅读 »
epoll是linux下高并发服务器的完美方案，因为是基于事件触发的，所以比select快的不只是一个数量级。
单线程epoll，触发量可达到15000，但是加上业务后，因为大多数业务都与数据库打交道，所以就会存在阻塞的情况，这个时候就必须用多线程来提速。
业务在线程池内，这里要加锁才行。测试结果2300个/s
继续阅读 »
epoll是linux下高并发服务器的完美方案，因为是基于事件触发的，所以比select快的不只是一个数量级。
单线程epoll，触发量可达到15000，但是加上业务后，因为大多数业务都与数据库打交道，所以就会存在阻塞的情况，这个时候就必须用多线程来提速。
下面是来一个网络连接创建一个线程处理业务，业务处理完，线程销毁。实际测试结果不是很理想，在没有业务的时候的测试结果是2000个/s
继续阅读 »
平时对网络编程方面比较感兴趣，看了一些相关的资料，自己也尝试写过一些不同网络模型的服务程序。这次刚好有一个新的需求，需要开发一个转发服务器。之前开发的项目，网络通讯都是处理联机交易的，网络连接都是采用短连接，这次的服务端，采用长连接的方式。
继续阅读 »
GDB的功能很强大，本文主要介绍用GDB来调试信号、多进程、多线程，具体如下：
（一）信号
GDB有能力在你调试程序的时候处理任何一种信号，你可以告诉GDB需要处理哪一种信号。你可以要求GDB收到你所指定的信号时，马上停住正在运行的程序，以供你进行调试。你可以用GDB的handle命令来完成这一功能。
继续阅读 »
APUE上，关于条件锁。其中有这么几条总结：
1。使用条件锁前必须先锁住对应的互斥锁。
2。条件锁进入阻塞(pthread_cond_wait)时自动解开对应互斥锁，而一旦跳出阻塞立即再次取得互斥锁，而这两个操作都是原子操作。
继续阅读 »
近期评论