3 ms·

An intermediary-free broadcast system can easily be implemented by setting up a memory segment that is shared between processes. One process writes to the memo

An intermediary-free broadcast system can easily be implemented by setting up a memory segment that is shared between processes. One process writes to the memory segment, and many other processes can read from it (usually after being signaled to do so via a condition variable).

FooBarWidget 16y ago
I dispute the notion that it is "easy" and the implicit notion that it's better than a system with an intermediary. * Inter-process condition variables are not supported on all operating systems. The next best thing would be sockets or message queues but these don't support broadcasting. * Having multiple processes read and modify the same memory segment requires some kind of locking. Inter-process locks are expensive (or at least, more expensive than local-process locks) on most operating systems. On Linux a lock file is more expensive than a POSIX mutex. This can really kill performance compared to a system in which sockets are used to communicate with an intermediary and other bus listeners. * Any process can corrupt the shared memory segment and screw up the state of all other processes that use it. * With shared memory it becomes impossible to properly detect dead processes. Suppose a process connects to the bus and increases some kind of reference counter in the shared memory. If the process crash without properly decrementing the counter then other processes would never know that the number of processes would have gone down. You can add checks like checking whether other PIDs still exist but this is unreliable and kills performance. If you can prove me wrong, that'd be great, because I'm looking for an IPC mechanism that's faster than Unix domain sockets. I tried inventing my own with shared memory and inter-process locks and couldn't get it nearly as fast as sockets.
- humbledrone 16y ago
  I didn't mean to implicate that using shared memory would be better than an intermediary. I do still think that implementing a simple broadcast mechanism with shared memory is fairly easy, provided that you have access to inter-process condition variables. If not, things do get a lot more complicated (e.g. polling, yuck). I don't think I can prove you wrong, per se. I do have a suggestion, though: have you tried using shared memory for data transfer, and using a UNIX socket for synchronization? Only a tiny bit of data would have to be transferred over the UNIX socket (shared memory address to read from, etc), and the rest of the data could be read via the shared memory.
- humbledrone 16y ago
  Another thing you might consider: lock free data structures. This C library for exactly that just hit the front page: http://www.liblfds.org/ http://www.liblfds.org/

FooBarWidget 16y ago

I dispute the notion that it is "easy" and the implicit notion that it's better than a system with an intermediary. * Inter-process condition variables are not supported on all operating systems. The next best thing would be sockets or message queues but these don't support broadcasting. * Having multiple processes read and modify the same memory segment requires some kind of locking. Inter-process locks are expensive (or at least, more expensive than local-process locks) on most operating systems. On Linux a lock file is more expensive than a POSIX mutex. This can really kill performance compared to a system in which sockets are used to communicate with an intermediary and other bus listeners. * Any process can corrupt the shared memory segment and screw up the state of all other processes that use it. * With shared memory it becomes impossible to properly detect dead processes. Suppose a process connects to the bus and increases some kind of reference counter in the shared memory. If the process crash without properly decrementing the counter then other processes would never know that the number of processes would have gone down. You can add checks like checking whether other PIDs still exist but this is unreliable and kills performance. If you can prove me wrong, that'd be great, because I'm looking for an IPC mechanism that's faster than Unix domain sockets. I tried inventing my own with shared memory and inter-process locks and couldn't get it nearly as fast as sockets.

humbledrone 16y ago
I didn't mean to implicate that using shared memory would be better than an intermediary. I do still think that implementing a simple broadcast mechanism with shared memory is fairly easy, provided that you have access to inter-process condition variables. If not, things do get a lot more complicated (e.g. polling, yuck). I don't think I can prove you wrong, per se. I do have a suggestion, though: have you tried using shared memory for data transfer, and using a UNIX socket for synchronization? Only a tiny bit of data would have to be transferred over the UNIX socket (shared memory address to read from, etc), and the rest of the data could be read via the shared memory.
humbledrone 16y ago
Another thing you might consider: lock free data structures. This C library for exactly that just hit the front page: http://www.liblfds.org/ http://www.liblfds.org/