[轉]Matz, Koichi訪談（三）：多執行緒

By Yuanyi ZHANG | Published: July 23, 2007 原文連結

問：讓我們談談多執行緒吧，這可以算是新版本比較大的改動了。你們分別談談1.8和1.9中的執行緒模型好嗎？

Matz：老的執行緒模型屬於綠色執行緒模型（最早出現於Java語言中，指執行緒不是由作業系統，而是由虛擬機器進行排程，詳細請參看維基百科），不管執行於那個平臺，它都只提供一個全域性唯一的執行緒。在14年前我開始開發Ruby時，這是一個正確的決定，但是隨著時間的推移，這個決定變得不再合適，因為大部分平臺上都已經提供了諸如pthread或者是類似的執行緒庫實現，pth庫（一個使用setjmp實現pthread API的執行緒庫）還提供了一個綠色執行緒實現。

Koichi決定在YARV中使用原生執行緒，我尊重他的決定。不過唯一的遺憾是，新版本中將無法繼續支援使用了原有執行緒模型內部資料結構的程式，儘管Koichi告訴我，繼續支援原有執行緒模型也不是完全不可能，但這在1.9的開發中肯定屬於低優先順序的任務。

Ko1：Matz解釋了原有的模型，那我就來解釋下新的吧！

就像你瞭解的，YARV支援原生執行緒，也就是說你現在可以同步地執行多個Ruby執行緒了。

但這並不意味著Ruby執行緒可以被並行執行，因為YARV使用了一個全域性的VM鎖，同一時間只有一個Ruby執行緒可以得到它。之所以這樣做，主要是考慮到相容為以前版本所編寫的C擴充套件（這些C擴充套件不需要做任何修改就可以執行在新版本上）。

問：那為什麼要做這個改變呢？以前的綠色執行緒有什麼問題嗎？

Matz：因為綠色執行緒不能很好地支援那些需要使用原生執行緒的庫，比如Ruby/TK就在Pthread方面花費了大量的時間。

Ko1：Ruby的綠色執行緒線上程切換時需要拷貝整個執行緒上下文，因此，效率是一個問題。當然更重要的是，我發現很難在YARV上實現綠色執行緒。

問：那麼原生執行緒實現會不會也有些副作用呢？

Matz：我認為最主要的問題就是它不能同老版本保持相容，同時它還無法實現真正的併發，不過，Koichi目前正在試圖通過多VM的方法來解決併發的問題。

Ko1：是的，原生執行緒確實存在一些問題。首先是效率問題，我們都知道，建立原生執行緒十分昂貴，因此如果你需要建立大量執行緒，那麼最好使用執行緒池。還有就是目前主幹中的多執行緒部分還沒有經過充分的測試，因此可能還隱含著一些未知的Bug。

第二就是可移植性，如果你的系統支援pthread，但是同其他系統的pthread實現有些差異的話，這可能會引發問題。

第三個問題是缺少命名支援，有些人可能用到了綠色執行緒的命名功能。

最後，目前的原生執行緒還存在一些問題，比如在MaxOS上，如果同時存在其他執行緒的話，執行exec（）會導致異常（一個移植性問題）。因此，如果我們發現原生執行緒的確存在一些較嚴重的問題的話，我將在YARV中提供綠色執行緒支援。

問：那麼你們是否有計劃在未來支援別的執行緒模型？

Matz：其他執行緒模型？還是不要了，win32和pthread已經夠我們忙活的了。不過未來我們可能會考慮加入並行化支援，就像Erlang中的輕量級程式。

Ko1：我目前最關心的就是如何讓Ruby支援平行計算。有好多種實現方法可供選擇，但是如果要讓多個Ruby執行緒在一個程式中並行執行，那麼恐怕許多C擴充套件都將因為同步問題而無法工作。

不過，就像Matz說的，我們可以考慮在一個程式中執行多個VM例項，這些VM可以並行執行，這個主題將成為我未來的主要研究方向。

另外，就像我在上一個問題所說的，如果原生執行緒的問題實在是太多太多，那我將考慮重新實現綠色執行緒，你也瞭解，綠色執行緒有許多優勢（比如輕量級的執行緒建立等等）。實際上，我的畢業論文就是關於如何在一個特定的SMT CPU上實現使用者空間的執行緒庫的，所以我想這對我來說會是個很有趣的過程。