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 ？

總結

以上是生活随笔為你收集整理的锁与高6)并发的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。