哪個IPC在這裏更高效？

我有一個系統應用程序，作爲unix上12個進程的集合運行。有一個監視進程，與其他11個進程交換數據。哪個IPC在這裏更高效？

IPC的要求是使這11個進程與監控進程進行通信，並以最有效的執行方式進行設計。你們可以衡量下面兩個選項，或者建議更好的選項。

1）有一個UDP套接字通信，其中這11個進程將定期將數據推送到監視進程。監控程序只是在監聽和捕捉足夠好的信息。

或

2）具有共享內存實現。所以共有11個共享內存段，每個共享內存段在兩個進程（進程第i個進程和監視進程）之間共享。

對於共享內存，它似乎更快，但需要鎖定/同步，在udp中，內核將數據從一個進程的內存空間複製到另一個進程。

任何人都可以提供更多的輸入來幫助更好地評估這兩種方法。？謝謝。

來源

2011-03-03 sbr

你真的是一個UDP套接字，或你是指Unix域套接字嗎？ – 2011-03-03 05:05:32

協調共享內存很棘手。父母必須知道何時讀取11個共享內存段中的每一個的哪個部分，並且讓孩子知道數據何時被讀取，以便部分共享內存可以被重用等等。因此，儘管複製可能是更快，其餘的協調（也許使用信號量集 - 可能有22個信號量，11個通信通道的每個方向一個）意味着您幾乎可以肯定會找到基於文件描述符的機制更容易編碼。可以使用select()或poll()或變體系統調用來告訴您什麼時候有主數據要讀取的數據。內核處理所有的調度和流量控制等問題。

因此，使用Unix域套接字，除非你真的能證明你會得到一個性能優勢出的共享內存版本。但是，期望會失去一些頭髮（和一些數據），使共享內存實現正確。（你能證明是否有性能優勢，使用共享內存粗，不當sycnhronized系統，你可能不會進入生產與原油同步不當的系統。）

來源

2011-03-03 08:49:30

這很大程度上取決於進程需要共享多少數據。如果要傳遞大量數據（例如兆字節或千兆字節），共享內存將是更有效的方式。如果只有將是一個相對較小的數據量（千字節或者一個幾兆字節），那麼基於套接字的方法可能會更好，因爲效率將不會是很大，並且避免共享內存會使你的系統更加強大，更容易開發和調試。另外，有些內核支持零拷貝網絡，在這種情況下，將UDP數據包從一個進程發送到另一個進程可能不需要內核根本複製數據，而只是將底層MMU頁面重新映射到目標進程。如果是這種情況，套接字方法會給你兩個世界的最好（效率和魯棒性）。

來源

2011-03-03 02:11:55

1）數據將按照avg：30 kb/min（載荷約60 kb/min）的順序排列。2）易於使用的代碼並不是一個問題，因爲我們有足夠的時間和精力來使其最具性能導向。 – sbr 2011-03-03 04:43:35

現代計算機（即使是現代嵌入式計算機）每分鐘60千字節的負載是微不足道的。如果你的負載真的很低，那麼你實現的方式就很難了;幾乎任何合理的機制你都會獲得良好的表現。我不會花費太多的編程時間在一個複雜的機制上，但唯一的好處是您可能會看到0.01％的CPU使用率而不是0.02％。如果是我，我只會使用TCP（或UNIX）套接字。 – 2011-03-11 00:21:13

在UDP傳輸中不能保證，並且有時甚至在本地主機通信中丟包。所以MMF可能會更好。

來源

2011-03-03 08:01:38

哪個IPC在這裏更高效？

回答

相關問題