What are all the differences between pipes and message queues?

Question

What are all the differences between pipes and message queues?

Please explain both from vxworks & unix perspectives.

I think pipes are unidirectional but message queues aren't.

But don't pipes internally use message queues, then how come pipes are unidirectional but message queues are not?

What are the other differences you can think of (from design or usage or other perspectives)?

Lastex

I think in general they are the same thing. Message queues tend to make sure that the data arrives to the recipient. So they can persist the data until the recipient becomes available, but I guess this is not mandatory and is implementation dependent, just like uni/bidirectional, or persistent/single-message pipe etc... Pipes are used to send chunks of strings and binary data, while queues are used to send messages, but again, this can be implementation dependent. People like to reinvent the wheel if we are talking about messaging. Some of the terms have more than 5 different names... – Megadeath

Check this also quora.com/… – Foreleg

Answer 1

Message Queues are:

• UNIDIRECTIONAL
• Fixed number of entries
• Each entry has a maximum size
• All the queue memory (# entries * entry size) allocated at creation
• Datagram-like behavior: reading an entry removes it from the queue. If you don't read the entire data, the rest is lost. For example: send a 20 byte message, but the receiver reads 10 bytes. The remaining 10 bytes are lost.
• Task can only pend on a single queue using msqQReceive (there are ways to change that with alternative API)
• When sending, you will pend if the queue is full (and you don't do NO_WAIT)
• When receiving, you will pend if the queue is empty (and you don't do NO_WAIT)
• Timeouts are supported on receive and send

Pipes

• Are a layer over message Queues <--- Unidirectional!
• Have a maximum number of elements and each element has maximum size
• is NOT A STREAMING INTERFACE. Datagram semantics, just list message Queues
• On read, WILL PEND until there is data to read
• On write, WILL PEND until there is space in the underlying message queue
• Can use select facility to wait on multiple pipes

That's what I can think of right now.

Lothair

The task is in the pended state, meaning it is waiting for something to occur: in this case, the queue to have something in it (when reading) or have an empty slot (when writing). – Lothair

Answer 2

I also found this difference in IPC in UNIX. It states that the difference between them is that Message queues and pipes is that the first stores/retrieves info in packets. While pipes do it character by character.

Msg queue:

Message queue: An anonymous data stream similar to the pipe, but stores and retrieves information in packets.

Pipe

Pipe: A two-way data stream interfaced through standard input and output and is read character by character

I also found this question here: Pipe vs msg queue

Ilona

Answer 3

"VxWorks pipes differ significantly from UNIX pipes", says the vxWorks documentation, and they ain't kidding. Here's the manpages.

It looks like it would not be exaggerating much to say that the only similarity between Unix pipes and vxWorks pipes are that they're a form of IPC. The features are different, the APIs are different, and the implementations are surely very different.

Formenti

Answer 4

Comparison of message queues and pipes: - ONE message queue may be used to pass data in both directions - the message needn't to be read on first in-first out basis but can be processed selectively instead source: see http://www.cs.vsb.cz/grygarek/dosys/IPC.txt

Artefact

Answer 5

MQs have kernel persistence, and can be opened by multiple processes.

Formenti

Ken, I'm not sure what you're saying... In the context of vxWorks, pipes can be opened by multiple processes. I'm not sure what kernel persistence means. – Lothair

It appears that vxWorks "pipes" are very different from "pipes" on pretty much every other modern operating system. You can assume my answer applies to every non-vxWorks system. :-) – Formenti

Kernel persistence means it persists as long as the kernel does, as opposed to filesystem persistence, process persistence (which pipes have, at least on Unix), etc. – Formenti