Clojure通過使用無鎖定算法lockfree？

Question

我在Clojure任務中取得了進步（在4clojure.com上解決了大約80個問題），我一直在閱讀和編碼，並試圖「明白」。

現在我對Clojure被設計用於「無鎖併發」感到困惑。我非常清楚死鎖問題（如：「我編寫的代碼很糟糕，最終導致死鎖」，而不是「我在併發專家」）。我也看到了這一點：

Why is lockless concurrency such a big deal (in Clojure)?

我意識到它是多麼偉大的，Clojure程序不能死鎖。但是我有點困惑：是通過在無鎖無鎖算法下實現這樣一個壯舉，還是使用了可能的「死鎖」算法，但是使用正確的實現保證永遠不會死鎖（這會以某種方式被隱藏「給Clojure程序員）？

還有的是Hacker News上最近的討論有關lockfree算法：

http://news.ycombinator.com/item?id=4103921

參考以下「無鎖算法」頁1024cores.net：

http://www.1024cores.net/home/lock-free-algorithms

我不明白這篇文章和如何併發性之間的關係在Clojure下工作。

它讓我完全困惑：當我在Clojure中開發併發程序時，是否意味着「鎖和無鎖算法」對我來說不是問題？

Answer 1

一般而言，Clojure通過正確處理時間避免了鎖的問題在許多系統中，對象的時間是一個非常鬆散的概念，因爲時間1（更新前）的對象被編輯到位以成爲該對象time-2（更新後），在這個過程中，它既是第一個也是第二個，所以我們使用鎖來確保它在這個轉換之前或之後纔可見。由此產生的協調鎖和死鎖從此...

它是算法，數據結構和時間的組合。

Clojure通過結合不可變數據結構，函數式編程和協調時間模型（參考，原子，代理等）完成。在這個模型的功能需要的東西，產生它的下一個版本，同時保留了過去，只要有人在看它（直到GC得到的話）

• 不可變的數據結構：Clojure的集合在持續FP的意義。新版本發佈後，舊版本「堅持」。這樣觀察者不需要鎖定對象，因爲它們永遠不會從它們下面改變。較新版本可能存在基於他們正在查看的版本，但沒有任何內容會更改它們的副本。函數式編程：純粹的（或儘可能接近無差別）函數在一個時間點採集一個集合，併產生下一個版本而不共享其內部狀態，因此不需要鎖定。這還有很多其他的好處。

• Coordinated time：什麼時候需要多個對象進行協調，因爲與任何有趣的系統的話，那麼Clojure的時間模型的用武之地。對於不同的目的有不同的機制。這有一個內部用於計算時間增量的鎖，因此只有一個時間爲零，一次和一次N.因此它不是嚴格無鎖的。 的STM包含鎖，你永遠*需要與

---

*嗯......幾乎從不;-)

Answer 2

如果你周圍的Clojure的源grep和特別的互動.java文件，你會發現很多關於java.util.concurrent軟件包的參考資料。 java.util.concurrent包是紐約州立大學奧斯威戈分校Doug Lea幾十年併發研究的高潮。具體來說，引用了允許訪問「比較和交換」（也稱爲「比較和設置」，或CAS）instruction的原子可變類（例如AtomicReference）。 CAS指令有點難以解釋（我在下面提供了一個參考），但正確使用CAS是算法「無鎖」（至少在Java世界）意味着什麼的核心。無鎖算法最終可以爲高併發應用程序提供更高的吞吐量和更少的爭用;恰恰是Clojure所瞄準的領域。

想要深入瞭解這個主題，請閱讀Brian Goetz的Java Concurrency in Practice。另請參見同一作者的此article。

作爲一個方面說明，我總是發現很難直接使用java.util.concurrent包，即使它發展了。它對我來說只是感覺太低。關於Clojure的奇妙之處在於它提供了對專家併發庫的訪問，但卻通過非常易於使用的軟件事務內存（STM）抽象。這真的是一個成就。