2009/04/05

fork()與vfork()的比較

節錄自:大黑狗 之 嵌入式系統專案實務 與 產業觀察

fork()和vfork()這兩個系統功能都可以複製出和呼叫者﹙parent﹚完全相同的processchild﹚,但呼叫vfork()後的parent process會被暫停,直到被複製出來的child process執行了exec()exit();而呼叫fork()後的parent process會和新產生的child process平行﹙concurrent﹚執行。

接下來我們必須約略解釋一下fork()Linux中的實現方式,旨在讓讀者知道為什麼這個系統功能沒法直接移植到沒有MMUCPU上;首先我們必須先介紹一下”copy-on-write”這個觀念:

一個程式在執行時會佔據記憶體空間,粗略可分為程式段、資料段、堆疊段與常數段,其中程式段與堆疊段是唯讀的,資料段與堆疊段的內容則有可能在執行時期被改變。在Linux中,當某個process呼叫fork()產生child process時,系統只會為新的process配置堆疊段,其他的記憶體區段都是共用的;實際上在child process呼叫exec()去執行另一個程式前,諸如程式段以及常數段這些內容不可以被改變的記憶體區段始終可以共用。可是資料段就不能一直共用,如果parentchild process同時去操作某個變數勢必會引起混亂。

Child processfork出來後馬上呼叫exec()去執行其他程式是最常用的流程,以此說來,雖然每個process都必須有獨立的資料段,但馬上為child process配置資料段是很不經濟的,因為在大部分的狀況下child process並不會去對資料段作寫入的動作,在執行exec()後,之前的資料段就沒用了。

為了解決這個問題,Linux(fork)採用”copy-on-write”的技術,在child process尚未對資料段作寫入的動作之前,parentchild process共用資料段;當child process對資料段記憶體作出寫入的要求時,系統會配置一塊實體記憶體﹙一個page﹚給child process,並將原本資料段中被要求寫入之page的內容複製到這塊新的page;接著系統會更改child process的page table,使要被寫入資料的虛擬位址可以對應到上述新配置的實體記憶體位址。

此時child processparent process的資料段大部分都還是功用的,不同的地方只是這次要被寫入的page;這種演算法的好處很多,在最節省記憶體的前提下使得parentchild process不致互相影響。要達到這種效果,CPU沒有支援MMU是做不到的,所以uClinux無法直接支援fork()這個系統功能。

uClinux無法作到安全的資料段分享機制,產生child process後複製整塊資料段也顯得有點笨拙,於是只好讓parent process停止執行,直到child process結束執行或有了自己的資料段之後才能恢復執行,前者表示child process出現例外或呼叫了_exit(),而後者則表示child process呼叫了exec()去執行其他的程式。這樣妥協出來的功能,就是原本Linux中的vfork()系統呼叫。

如果讀者對copy-on-write的原理不清楚也沒關係,讀者在使用uClinux時只需知道一般Linux在實現fork()這個系統功能時必須用到MMU的機制,而uClinux執行在沒有MMUCPU之上,所以fork()無法直接移植到uClinux上;uClinux提供vfork()以達到多工的效果。

必須注意的是,使用vfork()產生的child process很可能會破壞parent process原本的資料段,所以程式設計師在uClinux上使用vfork()時必須格外小心;而且沒有fork()系統功能的事實使得許多原本運行在Linux上的應用程式無法完全不經修改救執行於uClinux之上。

我的心得:在早期的fork會複製整個parent的address space,造成時間的浪費,使用vfork則不會複製parent的address space。近來的fork則使用copy-on-write的技術,但是這卻需要MMU的幫忙,才能將child process的page table修改成正確的physcial address,而在嵌入式系統上,uClinux並不支援MMU,所以只能使用vfork。


1 則留言:

匿名 提到...

粗略可分為程式段、資料段、堆疊段與常數段,其中程式段與堆疊段是唯讀的,資料段與堆疊段的內容則有可能在執行時期被改變。
---------------------
請問唯獨的是否應該為 程式段與常數段?

2024年React state management趨勢

輕量化 在過去Redux 是 React 狀態管理的首選函式庫。 Redux 提供了強大的功能和靈活性,但也帶來了一定的學習成本和複雜度。 隨著 React 生態的不斷發展,越來越多的開發者開始追求輕量化的狀態管理函式庫。 Zustand 和 Recoil 等庫以其簡單易用、性...