IPC System V vs POSIX IPC


84
  1. Jakie są różnice między System V IPCi POSIX IPC?
  2. Dlaczego mamy dwa standardy?
  3. Jak zdecydować, których funkcji IPC użyć?

2
Był jeden powód, dla którego wybrałem kolejki komunikatów sysv zamiast posix. Możliwość dostarczania wiadomości przez mtype nie jest obsługiwana w kolejce komunikatów POSIX. Miałem blogu o tym ..
takladev

W książce zatytułowanej Linux Programming Unleashed 2nd Edition autorstwa Kurta Wall'a , strona 382, ​​jest napisane: System V IPC is well known and commonly used, but the Linux implementation of it is badly broken. Nie wiem, czy wprowadzono ulepszenia Linuksa w celu rozwiązania tego problemu, jeśli ktoś wie, proszę powiedzieć. Dzisiaj zbytnio stoję przed podobnym wyborem, jak Posix IPC lub System V IPC i moje podejście polega na dokładnym zrozumieniu, jaki typ prymitywów IPC będzie używany, ponieważ jeden z nich ma przewagę nad drugim. Na przykład proces może nagle umrzeć i co wtedy?
eigenfield

Odpowiedzi:


106

Oba mają te same podstawowe narzędzia - semafory, pamięć współdzieloną i kolejki wiadomości. Oferują nieco inny interfejs niż te narzędzia, ale podstawowe pojęcia są takie same. Jedną zauważalną różnicą jest to, że POSIX oferuje pewne funkcje powiadamiania dla kolejek wiadomości, których Sys V. (Zobacz mq_notify().)

Sys V IPC istnieje już od dłuższego czasu, co ma kilka praktycznych konsekwencji -

Po pierwsze, POSIX IPC jest mniej rozpowszechniony. Napisałem opakowanie Pythona dla POSIX IPC, a jego dokumentacja zawiera listę tego, co wiem o implementacjach POSIX IPC na różnych platformach .

Na wszystkich platformach wymienionych w tej dokumentacji, Sys V IPC jest całkowicie zaimplementowany AFAIK, podczas gdy możesz zobaczyć, że POSIX IPC nie.

Drugą konsekwencją ich względnego wieku jest to, że POSIX IPC został zaprojektowany po tym, jak Sys V IPC był używany przez jakiś czas. Dlatego projektanci POSIX API mogli uczyć się na mocnych i słabych stronach API Sys V. W rezultacie POSIX API jest prostsze i łatwiejsze w użyciu IMO i polecam go zamiast API Sys V.

Powinienem zauważyć, że nigdy nie przeprowadzałem żadnych testów wydajności, aby porównać te dwa. Myślę, że starszy interfejs API (Sys V) miałby więcej czasu na dostrojenie wydajności, ale to tylko spekulacje, które oczywiście nie zastąpią testów w świecie rzeczywistym.

Co do tego, dlaczego istnieją dwa standardy - POSIX stworzył ich standard, ponieważ uważali, że jest to ulepszenie standardu Sys V. Ale gdyby wszyscy zgodzili się, że POSIX IPC jest lepszy, wiele, wiele programów nadal używa Sys V IPC i przeniesienie ich wszystkich do POSIX IPC zajęłoby lata. W praktyce nie byłoby to warte wysiłku, więc nawet gdyby od jutra cały nowy kod korzystał z POSIX IPC, Sys V IPC pozostałby przez wiele lat.

Nie możemy Ci powiedzieć, którego powinieneś użyć, nie wiedząc o wiele więcej o tym, co zamierzasz zrobić, ale odpowiedzi, które tutaj masz, powinny dostarczyć Ci wystarczających informacji, aby zdecydować samodzielnie.


2
Jest jedna ważna różnica, której strony podręcznika i inne artykuły nie są w stanie uwydatnić, np. Kolejki komunikatów sysv mają pojęcie dostarczania komunikatów przez mtype (brakuje tego w msgq posix). W niektórych przypadkach może to być ważny element projektu i cytując moje doświadczenie, okazało się, że jest to blokada pokazu. Miałem blogu na ten temat.
takladev

Po dokumentacji OpenGroup, SysV IPC był częścią SUS od wydania 2 i nowego interfejsu od wydania 7. Rzeczywiście, jeden istnieje od dłuższego czasu, ale oba są częścią SUS, więc oba są częścią POSIX.
Hibou57

23
  1. Uważam, że główną różnicą jest to, że wszystkie POSIX IPC są bezpieczne dla wątków, podczas gdy większość SysV IPC NIE jest [ 1 ].
  2. Z powodu wojen uniksowych [ 2 ]. Specyfikacja Single UNIX (SUS) [ 3 ], znana również jako POSIX, została stworzona w celu standaryzacji interfejsów w systemach opartych na Uniksie.
  3. Prawdopodobnie chcesz POSIX. Zależy wyłącznie od Twoich wymagań.

11

System V IPC jest starszy, a POSIX IPC jest nowszy. Istnieją jednak pewne różnice w niektórych aspektach. Nie zawsze Posix jest lepszy niż System V.

  1. Semafory, kolejki i pamięć współdzielona dla Posix mają nazwy łańcuchów Ascii, podczas gdy w Systemie V są one podawane w postaci liczby całkowitej.

  2. Semafory Systemu V pozwalają na automatyczne zwolnienie, jeśli proces umrze (flaga semop SEM_UNDO). Nie ma czegoś takiego dla Posix.

  3. W Linuksie i FreeBSD kolejki posix mają dużą zaletę, ponieważ funkcje obsługi podane przez mq_open są w zasadzie deskryptorami pliku, który można odpylać / epolled / selected / kqueued.


Wydaje się zatem, że wybór zależy od typu prymitywnego IPC, który będzie używany. Są takie, w których Posix jest świetny, ale są też inne, w których System V jest świetny. Jeśli proces umiera nagle i żadne API na świecie nie może przechwycić takiego zdarzenia, wtedy prymitywy IPC zwisają lub w ten sposób zostaną wykryte. Istnieją różne przypadki użycia, w których Posix jest najlepszy, a są też inne przypadki użycia, w których System V dobrze sobie z tym radzi.
eigenfield

-3
  • Systen V i POSIX IPC to dwie różne, ale powiązane ze sobą implementacje tej samej rzeczy.

„Unix System V, powszechnie skracany do SysV (i zwykle wymawiany - choć rzadko zapisywany - jako„ System Five ”), jest jedną z pierwszych komercyjnych wersji systemu operacyjnego Unix. Został pierwotnie opracowany przez American Telephone & Telegraph (AT&T) i wydany po raz pierwszy w 1983 r. ”

-Wikipedia

„POSIX lub„ Portable Operating System Interface [for Unix] ”to nazwa rodziny powiązanych standardów określonych przez IEEE w celu zdefiniowania interfejsu programowania aplikacji (API)”

-Wikipedia

  • Systm V był tam wcześniej. POSIX wyewoluował z inicjatywy standaryzacji IEEE.

  • GNU / Linux jest partiallyzgodny z POSIX. To, którego użyć, zależy od używanego systemu operacyjnego. Większość dostawców zmierza w kierunku POSIX.

Programowanie sieciowe w systemie Unix: Komunikacja międzyprocesowa v. 2 autorstwa Richarda Stevensa daje dobry wgląd w oba te sposoby.

Programowanie sieciowe w systemie Unix


5
Nie omawiasz niczego na temat komunikacji międzyprocesowej, o której mowa w pytaniach.
Michael Rice
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.