What are the main disadvantages of Windows pipes for inter-process communication?

Question

Say you are splitting a monolithic Windows program into reusable components which could communicate with each other using some sort of inter-process communication (IPC), and, for whatever the reason, you choose anonymous pipes (e.g. starting a number of Process-es and connecting Console.Out to Console.In of the next process, or just using "|" in the command prompt).

A Dr. Dobbs article with an example with named pipes:

What would be the performance penalty compared to other IPC methods within the same machine? And what would be the first problem to hit when scaling up in the number of processes or the amount of data being transmitted?

E.g. If instead of pipes we were using files we would hit locking issues and disk speed.

Note that by having to serialise the data structures being transmitted there is already an overhead, which is my baseline for loss of efficiency.

PS. The interest in pipes is because they are easy to implement in each process (Console.Readline, Console.WriteLine), it's easy to write MSMQ and async HTTP interfaces to them, and for the love of Unix and the command line.

Answer 1

You can create two-way anonymous pipes using CreatePipe() Win32 API call, so piping input/output is not the only way. You simply get a new file handle you can give to the other process.

Anonymous pipes are based on shared memory, but do not support asynchronous operations (through ReadFileEx, ReadFileWrite). Performance issues (disadvantages) are thus 1) synchronous operation, 2) memory copying, 3) interprocess synchronization. Generally, "raw" shared memory (memory mapped file without an actual backing file) and named pipes will be faster, and sockets and Window messages will be slower (than anonymous pipes).

You cannot use I/O Completion Ports (IOCP) with anonymous pipes, instead you'll have to "poll" the pipe, incurring extra context switches. In addition to serializing the data, the serialized data has to be copied around in memory, as you cannot write directly to the shared memory. One process also has to wait for another, implying that the other process has to signal an interprocess synchronization primitive. Performance depends heavily on the size of the messages (ratio of read/write calls to amount of data sent), because for each read/write the process has to make context switches and possibly spin/sleep.

All methods except "raw" shared memory require memory copying and some sort of interprocess signaling (synchronization), so the main disadvantage of anonymous pipes is synchronous operation. You'll hit the ceiling when transmitting large number of messages, when the CPU spends most of its time doing context switches.

Performance-wise, named pipes are better because you can have worker thread(s) processing async notifications using IOCP, and can even receive multiple messages with one call, thus reducing the API overhead. If making your own components, the extra trouble from giving a name to the pipe is well worth the trouble (and you can even connect across networks). Later Windows versions implement special routing for local sockets, which also do support IOCP.

The fastest method would be to use shared memory directly, but then you will have to take care of interprocess synchronization yourself. It's possible to implement lock-free pipes yourself, but in case you're not constantly transmitting data, you'll still have to use synchronization primitives to notify/wake the listening process up.

Also note that using files does not imply that you would be limited by disk speed, as you can use memory mapped files and even with normal files, the cache manager handles the reading/writing. The other methods (RPC, clipboard, etc) are based on these "standard" methods, which means they'll just add some extra layer of protocol and are meant to be easier/more helpful, or more suitable for some programming environment (but not to be faster).