Difference between pipe and message queues(POSIX)
Shared memory is exactly what you'd think: it's an area of storage that can be read and written by more than one process. It provides no inherent synchronization; in other words, it's up to the programmer to ensure that one process doesn't clobber another's data. But it's efficient in terms of throughput: reading and writing are relatively fast operations.
A message queue is a one-way pipe: one process writes to the queue, and another reads the data in the order it was written until an end-of-data condition occurs. When the queue is created, the message size (bytes per message, usually fairly small) and queue length (maximum number of pending messages) are set. Access is slower than shared memory because each read/write operation is typically a single message. But the queue guarantees that each operation will either processes an entire message successfully or fail without altering the queue. So the writer can never fail after writing only a partial message, and the reader will either retrieve a complete message or nothing at all.
Also the following information is useful for difference between shared memory and message queues
When using shared memory with consideration for possible race-conditions where one process writes to it and another reads from it, something to bear in mind. There is an associated risk of using the former, suppose two processes are using it, one to write to it, the other to read from it, the one that is writing dies due to abnormal condition, the process reading it could hang or crash.
Shared memory can be deemed as faster (low overhead, high volume of data passing) then queues. But queues on the other hand, requires high overhead (the set up for making a queue to be permanent etc) with low volume of data.
The onus with shared memory is that you have to implement synchronization in order to be thread safe. Have a look at the excellent article by Beej on IPC.
When using Queues, they are thread-safe, and not alone that, messages are held in the queue regardless of the outcome, suppose two processes are using the queue, when one process writes to it (in a form of a message) and the other process that is about to read from it gets to die or killed off due to a crash or abnormal condition under a such circumstance, that message is still in place, the other process if restarted can read from the queue, i.e. no data is lost.
- Pipes aren't limited in size, message queues are.
- Pipes can be integrated in systems using file descriptors, message
queues have their own set of functions, though linux supports
select(),poll(),epoll()and friends on themqd_t. - Pipes, once closed, require some amount of cooperation on both sides to reestablish them, message queues can be closed and reopened on either side without the coorporation of the other side.
- Pipes are flat, much like a stream, to impose a message structure you would have to implement a protocol on both sides, message queues are message oriented already, no care has to be taken to get, say, the fifth message in the queue
Shared memory is exactly what you'd think: it's an area of storage that can be read and written by more than one process. It provides no inherent synchronization; in other words, it's up to the programmer to ensure that one process doesn't clobber another's data. But it's efficient in terms of throughput: reading and writing are relatively fast operations.
A message queue is a one-way pipe: one process writes to the queue, and another reads the data in the order it was written until an end-of-data condition occurs. When the queue is created, the message size (bytes per message, usually fairly small) and queue length (maximum number of pending messages) are set. Access is slower than shared memory because each read/write operation is typically a single message. But the queue guarantees that each operation will either processes an entire message successfully or fail without altering the queue. So the writer can never fail after writing only a partial message, and the reader will either retrieve a complete message or nothing at all.
Also the following information is useful for difference between shared memory and message queues
When using shared memory with consideration for possible race-conditions where one process writes to it and another reads from it, something to bear in mind. There is an associated risk of using the former, suppose two processes are using it, one to write to it, the other to read from it, the one that is writing dies due to abnormal condition, the process reading it could hang or crash.
Shared memory can be deemed as faster (low overhead, high volume of data passing) then queues. But queues on the other hand, requires high overhead (the set up for making a queue to be permanent etc) with low volume of data.
The onus with shared memory is that you have to implement synchronization in order to be thread safe. Have a look at the excellent article by Beej on IPC.
When using Queues, they are thread-safe, and not alone that, messages are held in the queue regardless of the outcome, suppose two processes are using the queue, when one process writes to it (in a form of a message) and the other process that is about to read from it gets to die or killed off due to a crash or abnormal condition under a such circumstance, that message is still in place, the other process if restarted can read from the queue, i.e. no data is lost.
No comments:
Post a Comment