Как программы общаются между собой

На самом деле способов обмена данными между процессами достаточно много и там есть как "универсальные", присутствующие практически на любой платформе, так и специфические для той или иной платформы.

К универсальным я бы прежде всего отнес сокеты (в т.ч. и UNIX sockets - локальные именованные сокеты, не привязанные к адресу/порту), пайпы, разделяемая память.

В какой-то степени - семафоры, хотя там сильно ограничена возможность передачи информации, это скорее событийный инструмент.

Специфические - например майлслоты (Windows) или очереди (Data Queue/User Queue - AS/400). На той же AS/400 есть еще т.н. User Space - нечто типа файла в памяти. Возможно, на других платформах есть что-то еще с чем не приходилось сталкиваться.

У нас в работе достаточно часто приходится с этим работать, правда, преимущественно для распределения обработки больших объемов данных на несколько заданий - есть головное задание, занимающееся отбором информации подлежащей обработке, есть несколько заданий - обработчиков. И есть "конвейер" - пайп или очередь, куда головное задание выкладывает пакеты на обработку и откуда они разбираются обработчиками (конвейеров может быть несколько - основной конвейер для данных, служебный конвейер для передачи служебной информации, например, команд, обработчикам и т.п.).

В такой схема скорость конвейера не сильно критична т.к. все упирается в скорость обработки данных. Тут скорее головное задание должно следить за степенью его заполнения - чтобы не "пересыхал" и не переполнялся (тут можно автоматически балансировать количество обработчиков - если конвейер пересыхает - можно остановить один из несколько обработчиков послав им соответствующую команду, если переполняется - запустить дополнительный обработчик).

Есть и другой подход - каждая программа создает свой "почтовый ящик" - майлслот (или UNIX Socket) со своим уникальным именем и тогда все остальные могу ей в этот ящик передавать нужную информацию. Такое тоже практиковал. Но это для других типов задач.

Плюсом использования системных каналов связи (по сравнению с той же разделяемой памятью) является то, что тут нет проблем с синхронизацией - за это отвечает система. Но скорость меньше чем для разделяемой памяти. Если же пользоваться разделяемой памятью (или специфическим User Space), то придется самому заботиться о блокировках и уведомлениях об изменении состояния что достаточно сложно во-первых и чревато дедлоками во-вторых. Но это плата за высокую скорость обмена данными.

Ну очень грубо - и неполно, причём без пользы для понимания. Общее поле памяти (Fortran), да и просто стек - зря не упомянуты внятно. Семафоры прекрасно работают в кооперативной многозадачности. И, кстати, кооперативная работает значительно быстрее (когда работает) вытесняющей, потому применяется до сих пор (и потому эпплы так поздно на вытесняющую перешли).

Если делается описание на уровне сокетов и каналов - то большую часть можно было просто опустить, это сущности очень разных уровней, и одна часть поста никак не поясняет другую.

Предупреждение: в статье я буду упрощать и жертвовать точностью ради понятности.

При объяснении квантовой механики, жертвовать точностью приводит к уменьшению понятности.

Что именно семафорит плавательно-корабельно-парусное судно с иллюстративной фотографии?

Сокеты

Забавно. На фото одноконтактные бананы питания запихивают в двухконтактные тюльпаны звука...