Scala的併發模型環境下的Clojure期貨

Question

嗨，大家好：在接觸scala的Actors和Clojure的期貨後，我覺得這兩種語言都對多核數據處理有極好的支持。

但是，我仍然無法確定兩個模型的併發特性和優缺點之間的真實工程差異。這些語言在處理併發流程抽象方面是互補的還是反對的？其次，關於大數據問題，Scala社區明確繼續支持Hadoop（而clojure社區明確這麼做）還不清楚。 Scala開發人員如何與hadoop生態系統進行交互？

對這兩個問題的任何見解將不勝感激。

Answer 1

參與者提供了一種處理潛在的交織和同步控制的方法，當試圖讓多個線程一起工作時，交互和同步控制是不可避免的。每個actor都有一個消息隊列，它按順序逐個處理，以避免需要包含顯式鎖。在這種情況下，Future提供了一種等待演員響應的方式。

就Hadoop而言，Twitter剛剛發佈了一個專門用於Hadoop的庫，名爲Scalding，但只要該庫是爲JVM編寫的，它就可以使用任一種語言。

Answer 2

一些解決方案很好地由代理商/參與者解決，有些則不是。這種區別不是關於語言超過如何具體問題適合一般類別的解決方案。這是演員/代理人與參考文獻（非常短）的比較，試圖澄清該工具必須適合併發問題的觀點。

在分佈式情況下，參與者擅長沒有數據需要同時修改。如果你的問題可以純粹通過傳遞消息來表達，那麼演員就可以做到這一點。參與者在需要同時修改多個相關數據結構的情況下工作得很差。這是在銀行賬戶之間轉移資金的典型例子。

Clojure的ref s是一個很好的解決方案，很多線程需要同時修改同一個東西。它們擅長共享內存多處理器系統，如今天的個人電腦和服務器。除了銀行賬戶的例子，Rich Hickey（clojure的作者）使用棒球比賽的例子來解釋爲什麼這很重要。如果您想用演員代表棒球比賽，那麼在您移動球之前，所有球迷都必須發送一條消息，詢問它是在哪裏的......如果他們想要看球員接球，那麼球甚至會得到更復雜。

Clojure有cascalog，這使得寫作hadoop的工作看起來很像寫作clojure。