锁与高6)并发
1） mutex与spinlock
结论：冲突较少时用spinlock， 频繁时用mutex。 优化不太必要
http://www.parallellabs.com/2010/01/31/pthreads-programming-spin-lock-vs-mutex-performance-analysis/
2）锁竞争解决办法
---避免锁
---使用读写锁
---只锁住必要的东西
---使用轻量级原子操作
http://www.parallellabs.com/2011/10/02/lock-in-parallel-programming/
3）sequence coherence 与 cache coherence
编译器的优化可能违反sc, 但不优化性能损失太大， 因此出现c++11中的atomic类型
http://www.parallellabs.com/2010/03/06/why-should-programmer-care-about-sequential-consistency-rather-than-cache-coherence/
4）lock free与mutex
lock free高效，但优势极其有限。 而且lock free算法难实现。 不建议。 CAS， compare_and_swap; CAS2
http://www.cnblogs.com/liuhao/archive/2011/12/21/2295671.html
5） c++11 std::atomic 。 比mutex高效4倍，但是目前只是封装了简单数据类型
#include <atomic>
http://blog.csdn.net/yockie/article/details/8838686
可以找facebook的开源c++库
6）c100k 内核调优
http://joyexpr.com/2013/11/22/c100k-4-kernel-tuning/
http://blog.lifeibo.com/blog/2011/07/07/200-long-connection.html
7）half duplex 解决不了有锁的问题。
需求场景： gate server面向大量用户， 将用户请求转发给后端其他模块； gate与后端其他模块的连接数是有限、固定的。
这样，当后端回复response时， gate必需从client池子中找到对应的client 连接将数据发回去； 连接关闭或者建立时也要处理该client池子。
1） 如果是单线程， 性能会怎么样？
2） gate如果是多线程， 则必定有锁； 如何减少或者避免锁开销？
必需是多线程， 请求收到后， parse或者serialize将会比较耗cpu；
3） 单个连接，即便全双工模式， 也是不需要锁的。 使用strand。 strand不会阻塞线程。
但是另外的线程可能给该socket投递数据？ 如某线程可能操作某socket向外投递数据， 另外某线程想向该socket转交数据，以便该socket向外投递出去。
socket().io_serivice().post(.....);这个无需锁， 然后post中指定的回调函数使用strand包裹起来就行， 避免多线程同时操作写队列。
ioservice per cpu 或者多线程执行一个io_service::run， 都可行。
查看耗时
time ./program
profile && oprofile
一个tcp连接耗内存8k ？