Система V IPC проти POSIX IPC

84
  1. Які відмінності між System V IPCі POSIX IPC?
  2. Чому ми маємо два стандарти?
  3. Як вирішити, які функції IPC використовувати?
posix  ipc  sysv 
— Мегасям
джерело
2
У мене була одна причина, яка змусила мене вибирати черги повідомлень sysv замість posix. Можливість доставки повідомлень за mtype не підтримується в черзі повідомлень posix. Я писав про це в блозі ..
— takladev
У книзі під назвою Linux Програмування Unleashed 2nd Edition від Kurt стіни , сторінка 382, він сказав: System V IPC is well known and commonly used, but the Linux implementation of it is badly broken. я НЕ знаю , якщо поліпшення Linux були зроблені для вирішення цього питання, якщо хто - небудь знає , будь ласка , повідомте. Сьогодні я занадто стикаюся з подібним вибором Posix IPC або System V IPC, і мій підхід полягає в тому, щоб ретельно зрозуміти, який тип примітиву IPC буде використовуватися, оскільки є переваги в одному над іншим. Наприклад, процес може раптово померти і що тоді?
— eigenfield

Відповіді:

106

Обидва мають однакові основні інструменти - семафори, спільну пам’ять та черги повідомлень. Вони пропонують дещо інший інтерфейс до цих інструментів, але основні поняття однакові. Помітною відмінністю є те, що POSIX пропонує деякі функції сповіщення про черги повідомлень, яких Sys V не надає. (Див mq_notify().)

IPC Sys V існує довше, що має кілька практичних наслідків -

По-перше, POSIX IPC застосовується менш широко. Я написав обгортку Python для POSIX IPC, і в його документації перелічено те, що я знаю про реалізації POSIX IPC на різних платформах .

На всіх платформах, перелічених у цій документації, Sys V IPC повністю реалізований AFAIK, тоді як ви бачите, що POSIX IPC - ні.

Друге значення їх відносного віку полягає в тому, що POSIX IPC був розроблений після того, як Sys V IPC використовувався деякий час. Тому дизайнери API POSIX змогли навчитися на сильних і слабких сторонах API Sys V. Як результат, API POSIX простіший і простіший у використанні IMO, і я рекомендую його через API Sys V.

Слід зазначити, що я ніколи не проводив жодних тестів продуктивності, щоб порівняти ці два. Я вважаю, що у старішого API (Sys V) було б більше часу для налаштування продуктивності, але це лише припущення, яке, звичайно, не може замінити реального тестування.

Щодо того, чому існує два стандарти - POSIX створив їх, оскільки вони вважали, що це вдосконалення стандарту Sys V. Але якби всі погодились, що POSIX IPC є кращим, багато багатьох програм все ще використовують Sys V IPC, і для того, щоб перенести їх усі на POSIX IPC, потрібні роки. На практиці це не коштує зусиль, тому навіть якщо весь новий код використовує POSIX IPC з завтрашнього дня, Sys V IPC буде тривати довгі роки.

Ми не можемо сказати вам, що вам слід використовувати, не знаючи набагато більше про те, що ви маєте намір зробити, але відповіді, які ви маєте тут, повинні дати вам достатньо інформації, щоб вирішити самостійно.

— Пилип Семанчук
джерело
2
Є одна важлива відмінність, що man-pages та інші статті не виділяють, тобто черги повідомлень sysv мають поняття доставки повідомлень за mtype (цього немає в posix msgq). У деяких випадках це може бути важливим елементом дизайну, і, цитуючи мій досвід, це виявилося пробкою для шоу. Я писав про це в блозі .
— takladev
Після документації OpenGroup, SysV IPC був частиною SUS з випуску 2 та нового інтерфейсу, починаючи з випуску 7. Справді, один існує з тих пір, але обидва є частиною SUS, тому обидва є частиною POSIX.
— Hibou57,
23
  1. Я вважаю, що головна відмінність полягає в тому, що всі POSIX IPC є потокобезпечними, тоді як більшість IPC SysV НЕ [ 1 ].
  2. Через війни Unix [ 2 ]. Специфікації Single UNIX (SUS) [ 3 ], також відомий як POSIX, була створена для стандартизації інтерфейсів на системах Unix , заснованих.
  3. Напевно, ви хочете POSIX. Це залежить виключно від ваших вимог.
— jweyrich
джерело
11

Система V IPC старіша, а POSIX IPC новіша. Однак є деякі відмінності щодо деяких аспектів. Не завжди Posix кращий за систему V.

  1. Семафори, черги та спільна пам'ять для Posix мають імена рядків Ascii, тоді як у системі V вони даються з цілим числом.

  2. Семафори System V дозволяють автоматично звільнятися, якщо процес вмирає (прапорець semop SEM_UNDO). Для Posix такого немає.

  3. У Linux і FreeBSD є велика перевага черг posix, оскільки обробники, надані mq_open, є в основному дескриптором файлів, який може бути опитуваний / epolled / selected / kqueued.

— Мадарс Ві
джерело
Тоді здається, що вибір залежить від типу примітивного IPC, який буде використовуватись. Є деякі, де Posix чудова, а є й інші, де System V чудова. Якщо процес різко вмирає, і жоден API у світі не може перехопити таку подію, тоді примітиви IPC будуть звисати або тим самим виявляти їх. Існують різні варіанти використання, коли Posix є найкращим, а тоді є й інші випадки використання, коли System V добре вирішує проблему.
— eigenfield
-3
  • Systen V та POSIX IPC - це дві різні, але пов'язані реалізації одного і того ж.

"Система Unix V, яку часто називають SysV (і зазвичай вимовляється - хоча рідко пишеться - як" Система п'ять "), є однією з перших комерційних версій операційної системи Unix. Вона спочатку була розроблена American Telephone & Telegraph (AT&T) та вперше випущений у 1983 році ".

-Вікіпедія

"POSIX або" Портативний інтерфейс операційної системи [для Unix] "- це назва сімейства пов'язаних стандартів, визначених IEEE для визначення інтерфейсу прикладного програмування (API)"

-Вікіпедія

  • Systm V був там раніше. POSIX розвинувся внаслідок ініціативи IEEE щодо стандартизації.

  • GNU / Linux partiallyсумісний з POSIX. Який із них використовувати, залежить від того, яку ОС ви використовуєте цей IPC. Більшість продавців рухаються до POSIX.

Мережеве програмування Unix: Interprocess Communications v. 2, автор Річард Стівенс, дає хороший аналіз обох.

Мережеве програмування Unix

— Джестін Джой
джерело
5
Ви не обговорюєте нічого про Interprocess Communicaton, як зазначено в запитаннях.
— Майкл Райс,
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.