I need several client programs (stereo DSP audio generators) to be able to continuously, bidirectionally communicate with an external peripheral on an I2C bus, at a data rate of around 16kB/s with updates occurring every 1ms, all running on a 700MHz CPU. The programs will need simultaneous access to read and write but I don't care about locking on write.
I'm envisaging a daemon to manage the raw I2C communication, with the client audio programs communicating with the daemon via one of the following IPC options:
- DBUS
- Berkeley/POSIX sockets
- Memory mapped file
With DBUS I have performance concerns, and with Berkeley/POSIX sockets I'm not sure about handling multiple clients. It's also important that no locking occurs as the daemon communication has to happen in the same thread as the audio rendering.
Memory mapping appears to suit the task. 10 bytes should do it, I'd need 4 bytes for input, 4 bytes for output, some way of telling that daemon that it should write the output bytes now, and some way of telling the daemon that it should currently be continuously updating the input bytes. But as I understand it memory mapping relies on buffering by the operating system and so I'm not sure what would happen if my daemon updates the input bytes while my client app is in the middle of a read()
operation.
What's the best option for inter-process communication in my scenario?