Skip to main content

Interprocess Communication (IPC) on Linux

This chapter provides an overview of interprocess communication (IPC) mechanisms on Linux systems. The described mechanisms apply both to IPC between general Linux processes and specifically to IPC between one or more CODESYS Control SL runtime systems and other processes.

The mechanisms listed below are abstracted and made available by the Linux-based CODESYS runtime systems via CODESYS libraries.

Mechanism

Purpose

Relevant CODESYS Libraries

Notes

Typical Linux API

Shared Memory

Processes exchange large amounts of data simultaneously.

  • SysShm

  • Synchronization primitives: SysEvent, SysSemProcess

  • Shared memory allows for parallel reading/writing without copying

  • Access synchronization is strongly recommended, for example:

    • Atomic flags for reading/writing coordination

    • Events or semaphores for precise synchronization

  • shm_open + mmap

  • shm_close

POSIX semaphores (synchronization mechanisms)

Controls the access to shared resources or flow control

  • SysEvent

  • SysSemProcess

Blocking code in the IEC application should not cause large delays in cyclic operation and in cyclic IEC tasks.

  • sem_open

  • sem_wait/sem_try_wait/sem_clockwait

  • sem_post

  • sem_close

Sockets (UDP, TCP, Unix Domain Sockets)

Exchanges messages – either stream-based or packet-based – either locally or across hosts

  • Unix Domain Sockets provide significant performance advantages over TCP/UDP for local communication.

  • Network sockets allow for data exchange beyond device boundaries.

  • socket

  • accept/bind/listen/connect

  • read/write

  • close

Instructions for use

  • Technology-independent:

    The IPC mechanisms are not bound to a specific technology. The technologies can be combined in any way. Processes can be implemented in different languages or runtime environments, for example:

    • Native binaries (C/C++)

    • Python scripts

    • Java applications

    • IEC code from CODESYS

  • Modularization of IEC applications improves maintainability, fault tolerance, and scalability:

    Even for a single large IEC application, IPC can be useful to break it down into functional units, for example:

    • Motion

    • Fieldbus

    • Visualization

    • Data exchange / export

  • Benefits when native interfaces are missing:

    IPC can be used when a required API is not available in the desired technology.

    Example: A Python library contains a required functionality, but cannot be used directly in IEC → communication via Unix sockets or shared memory.

In this section: