TA貢獻1780條經(jīng)驗 獲得超4個贊
如果沒有對Python核心運行時進行深入和黑暗的重寫（以允許強制使用共享內(nèi)存的給定段并確保不同進程之間的地址兼容的分配器），就無法從任何一般意義上“共享內(nèi)存中的對象”。該列表將包含一百萬個元組的地址，每個元組均由其所有項目的地址組成，并且每個地址都將由pymalloc分配，這種方式不可避免地在進程之間變化，并遍及整個堆。
在Windows以外的幾乎所有系統(tǒng)上，都有可能產(chǎn)生一個子進程，該子進程本質(zhì)上具有對父進程空間中對象的只讀訪問權限……只要父進程也不會更改這些對象。可以通過致電獲得os.fork()，實際上是“快照”當前進程的所有內(nèi)存空間，并在復制/快照上啟動另一個同時進行的進程。在所有現(xiàn)代操作系統(tǒng)上，這都歸功于“寫時復制”方法：在分叉后未真正復制任一進程未更改的虛擬內(nèi)存頁面（實際上是共享對相同頁面的訪問） ; 一旦任何一個進程修改了先前共享頁面中的任何位，poof，即會復制該頁面，并修改了頁面表，因此修改過程現(xiàn)在具有其自己的副本，而另一個進程仍然看到原始頁面。
在某些情況下，這種極其有限的共享形式仍然可以挽救生命（盡管極為有限：例如，請記住，由于引用計數(shù)的原因，對共享庫添加引用將被視為“更改”該對象，因此將強制頁面復制?。?..當然除外，在Windows上除外。有了這個例外（我認為不會涵蓋您的用例），共享包含其他對象的引用/指針的對象圖基本上是不可行的-幾乎所有現(xiàn)代語言（包括Python）中感興趣的對象集屬于這種分類。
在極端（但足夠簡單）的情況下，可以通過放棄此類對象圖的本機內(nèi)存表示來獲得共享。例如，一百萬個元組的列表每個都有十六個浮點數(shù)，實際上可以表示為一塊128 MB共享內(nèi)存的塊-雙精度IEEE表示形式的所有16M浮點數(shù)首尾相連-帶有一點點填充要使它看起來像“頂”，您將以通常的方式解決問題（當然，畢竟不是那么簡單的填充程序還必須解決極其繁瑣的進程間同步問題，肯定會出現(xiàn);-)。從那里開始，它只會變得更加毛發(fā)且更加復雜。
現(xiàn)代并發(fā)方法越來越無視共享的方法，而無共享的方法更是如此，在這種方法中，任務通過消息傳遞進行通信（即使在使用線程和共享地址空間的多核系統(tǒng)中，同步問題和性能也會受到影響）當大面積的內(nèi)存同時被多個內(nèi)核主動修改時，會在緩存，流水線停頓等方面引起麻煩。
例如，Python標準庫中的多處理模塊主要依靠酸洗和來回發(fā)送對象，而不是共享內(nèi)存（肯定不是以R / W方式?。。?/p>
我意識到這對OP來說不是可喜的消息，但是如果他確實需要使多個處理器正常工作，那么他最好考慮將它們必須共享的任何內(nèi)容駐留在可以通過消息傳遞進行訪問和修改的地方- -數(shù)據(jù)庫，內(nèi)存緩存集群，除了將這些數(shù)據(jù)保留在內(nèi)存中并根據(jù)請求發(fā)送和接收它們之外什么也不做的專用進程，以及其他此類以消息傳遞為中心的體系結(jié)構(gòu)。
舉報