System V IPC vs POSIX IPC
Asked Answered
A

4

102
  1. What are the differences between System V IPC and POSIX IPC ?
  2. Why do we have two standards ?
  3. How to decide which IPC functions to use ?
Annoying answered 3/1, 2011 at 8:17 Comment(2)
There was one reason i had which led for me to chose sysv message queues over posix. The possibility of delivering messages by mtype is not supported in posix message queue. I had blogged about it..Volauvent
In the book titled Linux Programming Unleashed 2nd Edition by Kurt Wall, page 382, it said: System V IPC is well known and commonly used, but the Linux implementation of it is badly broken. I dunno if Linux improvements were made to address that issue, if somebody knows please tell. Today, i am too facing similar choice wither Posix IPC or System V IPC and my approach is to carefully understand the what type of IPC primitive is going to be used because there are advantages in one over the other. For example, a process can abruptly die and what then?Alleras
K
119

Both have the same basic tools -- semaphores, shared memory and message queues. They offer a slightly different interface to those tools, but the basic concepts are the same. One notable difference is that POSIX offers some notification features for message queues that Sys V does not. (See mq_notify().)

Sys V IPC has been around for longer which has a couple of practical implications --

First, POSIX IPC is less widely implemented. I wrote a Python wrapper for POSIX IPC and its documentation lists what I know about POSIX IPC implementations on various platforms.

On all of the platforms listed in that documentation, Sys V IPC is completely implemented AFAIK, whereas you can see the POSIX IPC is not.

The second implication of their relative age is that POSIX IPC was designed after Sys V IPC had been used for a while. Therefore, the designers of the POSIX API were able to learn from the strengths and weaknesses of the Sys V API. As a result the POSIX API is simpler and easier to use IMO, and I recommend it over the Sys V API.

I should note that I've never run any performance tests to compare the two. I would think that the older API (Sys V) would have had more time to be performance tuned, but that's just speculation which is of course no substitute for real-world testing.

As to why there are two standards -- POSIX created their standard because they thought it was an improvement on the Sys V standard. But if everyone agreed that POSIX IPC is better, many many many programs still use Sys V IPC and it would take years to port them all to POSIX IPC. In practice, it would not be worth the effort so even if all new code used POSIX IPC as of tomorrow, Sys V IPC would stick around for many years.

We can't tell you which you should use without knowing a lot more about what you intend to do, but the answers you have here should give you enough information to decide on your own.

Kerry answered 4/1, 2011 at 1:21 Comment(2)
There is one important difference that man-pages and other articles fail to highlight i.e. sysv message queues have a notion of delivering messages by mtype (posix msgq lacks this). In some cases, this could be an important design element and to quote my experience it turned out to be a show stopper. I had blogged about it.Volauvent
After OpenGroup’s documentation, SysV IPC was part of SUS since Issue 2 and the new interface, since issue 7. Indeed, one is there since more long, but both are part of SUS, so both are part of POSIX.Carroty
S
26
  1. I believe the major difference is that all POSIX IPC is thread-safe, while most SysV IPC is NOT [1].
  2. Because of Unix wars [2]. The Single UNIX specification (SUS) [3], aka POSIX, was created to standardise interfaces on Unix-based systems.
  3. You probably want POSIX. Depends exclusively on your requirements.
Searching answered 3/1, 2011 at 9:26 Comment(0)
C
16

System V IPC is older and POSIX IPC is newer. However there are some differences for some aspects. Not always Posix is better than System V.

  1. The semaphores, queues and shared memory for Posix have Ascii string names, while under System V these are given with integer number.

  2. The System V semaphores allows to be automatically released if process dies (semop SEM_UNDO flag). There is no such thing for Posix.

  3. On Linux and FreeBSD there is big advantage of posix queues, as handler given by mq_open are basically file descriptor which can be polled/epolled/selected/kqueued.

Canice answered 15/11, 2016 at 14:14 Comment(1)
It seems, therefore then, that the choice depends on the type of IPC primitive one is going to use. There are some where Posix is great, and yet there are others also where System V is great. If a process dies abruptly, and no API in the world can intercept such event, then the IPC primitives would be dangling or its detection thereby. There are varying use cases whereby Posix is best, and then there are other use cases wherein System V handles the issue well.Alleras
B
-4
  • Systen V and POSIX IPC are two different, but related implementations of the same thing.

"Unix System V, commonly abbreviated SysV (and usually pronounced—though rarely written—as "System Five"), is one of the first commercial versions of the Unix operating system. It was originally developed by American Telephone & Telegraph (AT&T) and first released in 1983."

-Wikipedia

"POSIX or "Portable Operating System Interface [for Unix]" is the name of a family of related standards specified by the IEEE to define the application programming interface (API)"

-Wikipedia

  • Systm V was there earlier. POSIX evolved out of the standardization initiative by IEEE.

  • GNU/Linux is partially compliant with POSIX. Which one to use depends on which OS you are using this IPC. Most vendors are moving towards POSIX.

Unix Network Programming: Interprocess Communications v. 2 by Richard Stevens gives a good look into both of these.

Unix Network Programming

Bertrambertrand answered 3/1, 2011 at 9:13 Comment(1)
You don't discuss anything about Interprocess Communicaton as referenced in the questions.Pimple

© 2022 - 2024 — McMap. All rights reserved.