StackDoc

StackDoc

當前位置: 主頁 > JAVA編程 > 多線程 >

False sharing問題及其解决方法

時間:2011-06-04 21:39來源:Internet 作者:Internet 點擊:
在做多線程程序的時候,为了避免使用锁,我們通常會采用這样的數據結構:根據線程的數目,安排一個數組, 每個線程一個項,互相不沖突. 從邏輯上看這样的設計無懈可擊,但是實踐的過程我們會發現這样並沒有提高速
?
在做多線程程序的時候,为了避免使用锁,我們通常會采用這样的數據結構:根據線程的數目,安排一個數組, 每個線程一個項,互相不沖突. 從邏輯上看這样的設計無懈可擊,但是實踐的過程我們會發現這样並沒有提高速度. 問題在於cpu的cache line. 我們在讀主存的時候,數據同時被讀到L1,L2中去,而且在L1中是以cache line(通常64)字節为單位的. 每個Core都有自己的L1,L2,所以每個線程在讀取自己的項的時候, 也把別人的項讀進去, 所以在更新的時候,为了保持數據的一致性, core之間cache要進行同步, 這個會導致嚴重的性能問題. 這就是所謂的False sharing問題, 有興趣的同學可以wiki下.

具體的参考文章: http://software.intel.com/en-us/articles/avoiding-and-identifying-false-sharing-among-threads/

解决方法很簡單:
把每個項湊齊cache line的長度,實現隔離.

typedef union {
    erts_smp_rwmtx_t rwmtx;
    byte cache_line_align__[ERTS_ALC_CACHE_LINE_ALIGN_SIZE(
				sizeof(erts_smp_rwmtx_t))];
} erts_meta_main_tab_lock_t;
或者
_declspec (align(64)) int thread1_global_variable;
__declspec (align(64)) int thread2_global_variable;

這就是为什麼在高性能服務器中到處看到cache_line_align, 號稱是避免cache的trash.

類似valgrind和intel vtune的工具可以做這個層次的性能微調.


From:http://blog.yufeng.info/archives/783
頂一下
(0)
0%
踩一下
(0)
0%
------分隔線----------------------------
發表評論
請自覺遵守互聯網相關的政策法規,嚴禁發布色情、暴力、反動的言論。
評價:
表情:
用戶名: 驗證碼:點擊我更換圖片
欄目列表
推薦內容
GOOGLE提供的廣告