消息傳遞與鎖定

Question

就性能而言，消息傳遞併發方案和基於鎖的併發方案之間的區別究竟是什麼？一個等待鎖定的線程，所以其他線程可以運行。因此，我看不出消息傳遞如何比基於鎖的併發更快。

編輯：具體地講，我討論一個消息傳遞方法等Erlang中，相比於使用鎖（原子操作或）的共享數據的方法。

Answer 1

當你想要做的只是鎖定時使用消息傳遞是錯誤的。在這些情況下，使用鎖定。然而，消息傳遞給你的不僅僅是鎖定 - 正如其名稱所暗示的，它允許你在線程或進程之間傳遞消息，即數據。

Answer 2

消息傳遞（使用不可變消息）更容易得到正確。通過鎖定和共享可變狀態，很難避免併發錯誤。

至於性能，最好自己測量一下。每個系統都不同 - 工作負載特性是什麼，依賴於其他操作結果的操作，還是它們完全或大部分是獨立的（這將允許大規模並行性），延遲或吞吐量更重要，有多少臺機器等。鎖定可能會更快，或者再次傳遞消息，或者完全不同。如果採用與LMAX相同的方法來解決手頭的問題，那麼也許可以。 （我將LMAX體系結構分類爲消息傳遞，儘管它與基於actor的消息傳遞非常不同。）

Answer 3

正如其他人提出的（「蘋果和橙子」），我將這兩種技術看作正交。這裏的基本假設似乎是一個會選擇一個或另一個：我們要麼使用鎖定和共享資源或我們將使用消息傳遞，並且一個呈現另一個不必要，或者其他甚至不可用。

很像，比如說，一個自循環直譯器，但不是很明顯這是真正的原語在這裏。例如，爲了實現消息傳遞，你可能會需要原子CAS和特定的存儲可見性語義，或者一些鎖和共享的狀態。可以用鎖來實現原子操作，或者可以在原子操作方面實現鎖定（就像Java在其java.util.concurrent.locks類型中那樣）。

同樣，但無可否認的拉伸，一個可以實現與消息傳遞鎖定。問一個更好的表現通常沒有什麼意義，因爲這實際上是一個關於哪個建立在哪個方面的問題。最有可能的，這是在較低的水平一個可以通過編程能夠比一個建在上面—由於一直採用手動變速器的汽車的情況下，直到驅動更好最近（相當多的辯論有太多）。

通常情況下，消息傳遞方式不稱讚更好的性能，而是爲了安全和方便，它通常通過拒絕鎖定和共享資源的程序員控制銷售。因此，它會針對程序員的能力而下注;如果程序員無法獲得鎖定，他不能很差地執行它，並減慢程序的執行速度。就像關於手動內存管理和垃圾收集的爭論一樣，有些人會聲稱是「好驅動程序」，充分利用手動控制;其他—特別是那些實施和促進使用垃圾收集器—的人將聲稱總體上，收集者可以比手動管理的「不太好的司機」做得更好。

沒有絕對的答案。這裏的區別在於程序員的技能水平，而不是他們可能使用的工具。

Answer 4

恕我直言，消息傳遞可能不完全是併發計劃。它基本上是（IPC）進程間通信的一種形式，它是共享對象的替代方案。 Erlang支持將消息傳遞給共享對象。共享對象的

缺點（優點OD消息傳遞）：

• 易變/共享對象的狀態是很難在多個線程同時運行一個上下文推理。
• 在共享對象上同步將導致本身不是wait free或非lock free的算法。
• 在多處理器系統中，可以跨處理器緩存複製共享對象。即使使用不需要同步的基於比較和交換的算法，也可能花費大量處理器週期將高速緩存一致性消息發送到每個處理器。
• 由消息傳遞語義構建的系統本質上具有更高的可擴展性。由於消息傳遞意味着消息是異步發送的，發送者不需要阻塞，直到接收者作用於消息。共享對象（消息傳遞的缺點）的

優點：

• 一些算法趨於簡單得多。
• 需要資源鎖定的消息傳遞系統最終會退化爲共享對象系統。在Erlang中，當程序員開始使用ets表等來存儲共享狀態時，這一點顯而易見。
• 如果算法是免等待的，您將看到改進的性能和減少的內存佔用量，因爲新消息形式的對象分配少得多。

Answer 5

消息傳遞不使用共享存儲器，這意味着它不需要鎖，引起每個線程（處理）只能加載或存儲其自己的存儲器，它們相互通信是發送&的方式接收消息。