Updating the question with more information:
I have 32 network namespaces on a Linux Ubuntu 14.04 box, and a C program runs in each namespace. I want the program to be able to share some data with it's siblings in other namespaces (not threads, separate processes). How can this be done? I cannot do a UDP multicast as each namespace has it's own networking stack and packets sent to a multicast domain is not visible to other namespaces. I am not able to think of doing this cleanly via mmap memory either.
With mmap(), each process may attempt to write to the map at the same time. Also, when one process writes, others should be able to figure that out, and update their data structure with this new content. They are allowed to write once every process knows about this previous update. This is why I first thought of using UDP Multicast socket to communicate, it works very nicely for 32 processes, but they have to be in the same namespace.
Also, Unix domain socket does not allow multiple reader/writers to work as far as I understand.
Appreciate any help!
32 processes in 32 network name spaces is already pretty significant, so I guess you want something serious and that can scale. Then I'd suggest you use a modern and scalable Linux IPC system.
Either d-bus,
or netlink sockets (which are not limited to networking stuff and will not interfere with your namespaces unless you want it). See here: "the netlink protocol is a socket based IPC mechanism used for communication [...] between userspace processes themselves."
It's for sure a heavier infrastructure (in term of software development work) compared to old school IPC such are shared memory, but you'll get the benefits of:
registration for events,
unicast/multicast/broadcast communication between your processes,
and much less race condition issues.
EDIT:
It feel a trend here for "yes, this can be done with regular Unix IPC".
And yes, sure, it can be done. It is done. For inspiration you may want to have a look at the Android property system design that rely on simple shared memory, and seems to have been pretty successful and scalable, isn't it? (and you even have the source code under a liberal license to study and fork - I do use this on non-Android embedded products).