Use two instances of a named pipe: one for one direction, another for another.
Now, why "sync"? A pipe is a thread synchronization primitive by yourself. Don't even try to use others (unless you share data beyond the pipes between the threads in the same application). You just unconditionally put data in the pipe. From the other side, you unconditionally read. Of course, prefer working with the pipes in a separate thread per pipe. So, just read. This is the blocking call. If the data is not available, your call will put your calling thread in a wait state: it will be switched off and never scheduled to execution, wasting no CPU during wait, until the thread is waken up. It can be waken up when data arrives, and also by some other conditions, such as timeout or thread abort.
If you use thread synchronization, it's where you use the shared data, from the pipe or not. This is a separate issue.
Now, I'm not sure you really need named pipes. You can use those pipes indirectly using "classical" .NET remoting or WCF (most likely, self-hosted on one or both sides). Both technologies use interchangeable
channels, and one kind of channels is called "IPC", which is, in both cases, based on named pipes.
Besides, I cannot be sure you really need communications between two processes. Many beginners try to use more than one process for one application, underestimated the hassles of such solutions and overestimating the difficulty of merging different modules in a single-process application. Form and console? Looks weird. Shouldn't one part be a Windows Service? You did not provide any detail, but I would strongly recommend you to critically review the architecture.
[EDIT]
Thank you for clarification. I would add one more idea: if the applications are already connected via sockets through the LAN, you can do the same for connecting different applications on the same computers. This is not an overkill: actually sockets were originally developed as the ICP facility. Only later the sockets interface was extended to cover network communications. They are more flexible, and you will reuse the code.
Likewise, you can use not sockets directly, but also "classical" .NET remoting or WCF with networking channels.
Networking can be done on different level. In my past answers, you can find my short overview of them:
how i can send byte[] to other pc[
^],
Communication b/w two Windows applications on LAN.[
^].
—SA
Submit an article or tip