※ 引述《easy1 (e :) y)》之銘言： : ※ 引述《adrianshum (Alien)》之銘言： : : 沒有什麼異想天開的，我記憶中我有做過類似的東西. : : 當然一般來說不會搞這些麻煩東西 XDD : 嗯 結果你印象中 這樣的做法"划算"嗎 : 效能有不錯嗎 (還有畢竟我沒寫過這種concurent程式..:-( ) : 如果讀/寫比例不會差太多的時候 我當時做是 C++ 的 XD 不過概念上沒有什麼不同 :P 划算嘛... 那還好，因為本身 map 中的物件不算多 （最多也只是幾千個），二來因為本身真的要有不少 update, 如果單一個 lock 的話是死定了. 跑起來也 沒有明顯的 performance 問題. 但我想這要視乎你自己的實際情況來決定了. 但簡單來說，物件不是太多，有頻繁的讀，但寫入也 不少的話，每個 entry 一個 lock 的做法該划算的，不然 synchronization 必定會成為 bottleneck : : 不會兩次 W lock. : : 一般來說的做法是，要新加入 entry, 才會acquire map 的 W lock. : : (新加入 entry 也不需取新 entry 的 W lock 哪） : : 修改現有的 entry 的話則只取 map read lock, 然後取 entry write lock. : : Alien : 嗯 我也這麼想 : 我現在想法是用 ConcurrentHashmap 搭配 map w/r lock 和 各各 entry 的 r/w lock : (ConcurrentHashmap支援同時更改map結構) : 我的需求大概是 讀/寫比 = 1.5 ~ 2 , entry 數量四位數.. 但同時讀的機會大嗎？ 大概有多少 thread 同時讀？ 比例有時不大有意思 比如只有一 read thread 一 write thread, 大概每 read 兩次就有一次 write, 這種情況不用 RW lock 也無妨。 : 如果簡單一點用 HashMap 加只有一個 map w/r lock : (有write 就lock整張map) : 看起來程式比較好寫 效能會差很多嗎...XD 這真的要看你自己的情況才知道了... 另，有提到會不會有太多 lock object，我以前有想過一個 解決方法但沒有實際 implement 過，你可以試試。 造一個 Lock Pool, 假設裡面有 30 個 lock 好了，每個加 入 map 的 entry 不是自己有一個獨立的 lock, 而是指向 Lock pool 中的某一個 Lock. 換句話就是幾個 map entry share 一個 Lock . 雖然這種做法會出現某 entry 的 read 會因為另一 entry 的 write 而被 block, 但至少是取平衡 的方法。 Alien Alien --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 219.77.26.195