陈硕的Blog

 当析构函数遇到多线程── C++ 中线程安全的对象回调 陈硕 (giantchen_AT_gmail)Blog.csdn.net/Solstice请尽量阅读本文 PDF 版：http://www.cppblog.com/Files/Solstice/dtor_meets_mt.pdf 豆丁亦可，内容略微滞后： http://www.docin.com/p-42460300

《Linux 多线程服务端编程：使用 muduo C++ 网络库》网上书店订购内容简介本书主要讲述采用现代 C++ 在 x86-64 Linux 上编写多线程 TCP 网络服务程序的主流常规技术，重点讲解一种适应性较强的多线程服务器的编程模型，即 one loop per thread。这是在 Linux 下以 native 语言编写用户态高性能网络程序最成熟的模式，掌握之后可顺利地开发各类常见的

看完了 W. Richard Stevens 的传世经典《UNIX 网络编程》， 能照着例子用 Sockets API 编写 echo 服务， 却仍然对稍微复杂一点的网络编程任务感到无从下手？ 书中示例代码把业务逻辑和 Sockets 调用混在一起，似乎不利于将来扩展？网络编程中的遇到一些具体问题该怎么办？例如程序在本机测试正常，放到网络运行上就经常出现数据收不全的情况？TCP 协议真的有所谓的“

PPT 见http://www.slideshare.net/chenshuo/efficient-logging-in-multithreaded-c-server/2012年6月30日在深圳的简短演讲：http://v.youku.com/v_show/id_XNDIyMjUwMDYw.htmlhttp://www.youtube.com/watch?v=KM_eQ6uRYdU代码位于 mud

这是一套紧凑的 PPT，基本上每一张幻灯片都可以单独写一篇博客，但是我没有那么多时间一一展开论述，只能把结论和主要论据列了出来。

内核专家 Bryan Cantrill 和 Jeff Bonwick 在 2008 年 9 月的《ACM Queue》上发表了《Real-world Concurrency》 一文，提出了 15 条并发编程的建议，这里简单摘录如下。 1. Know your cold paths from your hot paths. 弄清楚代码里的热门执行路径和冷门执行路径。 对冷门路径，用粗粒度的锁即可。对热门路径——也就是那些必须高度并发才能实现所期望的高吞吐量的代码，应该更加小心，加锁的策略必须简单明了且细粒

Muduo 是我在业余时间编写的基于 Reactor 模式的 C++ 网络库，适用于 Linux 平台，支持多线程。本文主要介绍 muduo 网络库的使用。其设计与实现将有另文讲解。

发布一个我自己业余时间编写的 C++ 多线程库 for Linux，这个库只有不到 1000 行源代码，封装了 pthreads 的常用功能（互斥器、条件变量、线程），实现了简单的线程池，并仿照 java concurrent 包编写了 BlockingQueue 和 CountDownLatch。库里的每个 class 都提供了使用样例。 这个库的内容：1. 整数的原子操作， AtomicInt32 和 AtomicInt64；2. 线程 Thread 和线程池 ThreadPool；3. 互斥器与条

陈硕 (giantchen_AT_gmail) Blog.csdn.net/Solstice 2010 March 3 - rev 01 《多线程服务器的适用场合》（以下简称《适用场合》）一文在博客登出之后，有热心读者提出质疑，我自己也觉得原文没有把道理说通说透，这篇文章试图用一些实例来解答读者的疑问。我本来打算修改原文，但是考虑到已经读过的读者不一定会注意到文章的变动，干脆另写一

陈硕 (giantchen_AT_gmail) Blog.csdn.net/Solstice 2010 Feb 28这篇文章原本是前一篇博客《多线程服务器的常用编程模型》（以下简称《常用模型》）计划中的一节，今天终于写完了。“服务器开发”包罗万象，本文所指的“服务器开发”的含义请见《常用模型》一文，一句话形容是：跑在多核机器上的 Linux 用户态的没有用户界面的长期运行的网络应用

 多线程服务器的常用编程模型 陈硕 (giantchen_AT_gmail)Blog.csdn.net/Solstice2009 Feb 12 建议阅读本文 PDF 版下载： http://files.cppblog.com/Solstice/multithreaded_server.pdf 本文主要讲我个人在多线程开发方面的一些粗浅经验。总结了一两种常

前几天，我发了一条微博 http://weibo.com/1701018393/A7FrW7ZVd ，质疑某本书对 Pthreads 条件变量的封装是错的，因为它没有把 mutex 的 lock()/unlock() 函数暴露出来，导致无法实用。后来大家讨论的分歧是这个 cond class 是不是通用的条件变量封装，还是只是一个特殊的“事件等待器”。作为事件等待器，其实现也是错的，因为存在丢失事件的可能，可以算是初学者使用条件变量的典型错误。