46

I am reading about various IPC mechanism. I am trying to figure out the scenarios, where we use Shared Memory and where we use named Pipes(FIFO).

Pipes: Multiple process can Write, however only one process can read. Write operation is atomic.

Shared Memory: Multiple process can read and write. And also user needs to provide mutual exclusion for read & write.

Is this the only difference of application of shared memory and pipe ?

Michał Kosmulski
  • 9,855
  • 1
  • 32
  • 51
vamsi
  • 1,727
  • 3
  • 22
  • 25

1 Answers1

72

Essentially, pipes - whether named or anonymous - are used like message passing. Someone sends a piece of information to the recipient and the recipient can receive it. Shared memory is more like publishing data - someone puts data in shared memory and the readers (potentially many) must use synchronization e.g. via semaphores to learn about the fact that there is new data and must know how to read the memory region to find the information.

With pipes the synchronization is simple and built into the pipe mechanism itself - your reads and writes will freeze and unfreeze the app when something interesting happens. With shared memory, it is easier to work asynchronously and check for new data only once in a while - but at the cost of much more complex code. Plus you can get many-to-many communication but it requires more work again. Also, due to the above, debugging of pipe-based communication is easier than debugging shared memory.

A minor difference is that fifos are visible directly in the filesystem while shared memory regions need special tools like ipcs for their management in case you e.g. create a shared memory segment but your app dies and doesn't clean up after itself (same goes for semaphores and many other synchronization mechanisms which you might need to use together with shared memory).

Shared memory also gives you more control over bufferring and resource use - within limits allowed by the OS it's you who decides how much memory to allocate and how to use it. With pipes, the OS controls things automatically, so once again you loose some flexibility but are relieved of much work.

Summary of most important points: pipes for one-to-one communication, less coding and letting the OS handle things, shared memory for many-to-many, more manual control over things but at the cost of more work and harder debugging.

Michał Kosmulski
  • 9,855
  • 1
  • 32
  • 51
  • 2
    Some minor correction. Pipes also may be created anonymously via the `pipe` syscall. Shared memory may also reside in the filesystem by not privately `nmap`ing a file. – johannes Dec 28 '12 at 12:56
  • 5
    FIFOs also support many-to-one communication (the "summary" implies only one-to-one). – Mark Rajcok Jan 04 '13 at 17:32
  • 2
    @MarkRajcok While possible, in practice having many writers with pipes is not very useful since there is no built-in mechanism to manage synchronization at the message level - whatever all the writers send will be interleaved in an unpredictable way. Even if external synchronization is implemented, the best one could do would be exclusive locking between the writers while each message is sent, which is not effective as only one can be writing at the same time. – Michał Kosmulski Jan 04 '13 at 20:20
  • 3
    If messages are always less than PIPE_BUF in size, I don't think you need to implement your own locking -- the messages will not be interleaved. Maybe I should have said "many-to-one with PIPE_BUF size limitation". – Mark Rajcok Jan 04 '13 at 22:16
  • 5
    @MarkRajcok You are correct, man for `pipe(7)` does state that if O_NONBLOCK is disabled and the number of bytes to write is less than PIPE_BUF, a call to `write(2)` is guaranteed to be atomic per POSIX.1-2001. On the other hand, the same man page contains the recommendation that "Different implementations have different limits for the pipe capacity. Applications should not rely on a particular capacity". So for specific cases multiple-writers scenario will work indeed, but I wouldn't base an application on it without a good reason. You never know what size of messages your may need sometime. – Michał Kosmulski Jan 06 '13 at 23:01