But the status should be read every 2-5 seconds so that there will be a huge system load to open the file and reading it all the time.
I think 8 processes doing this every two seconds will amount to something more like an "infinitesimal" load on the system. It depends a bit on how much they are reading from the file, but the bottleneck is (on the surface) I/O and so even 8 processes busy constantly reading from the SD card won't consume significant processor time; they all have to share the same bottleneck, and even at the theoretical maximum (25 MB/s) data coming from the SD card comes much slower than it does from, e.g., main memory, or could be run through the processor -- although this is also dependent on how much processing you have to do to it.
I'm guessing the volume of data is actually going to be small, so that won't matter much either. If it is say, < 1 kB, then that is 4 kB/s, and if you have a slow SD card (say 8 MB/s) that's still only 0.0005% of the available bandwidth. The SD card uses DMA, so the CPU will be mostly free to do other things (such as processing read data), or nothing during that time.
However, presuming you haven't used 100% of your free RAM, if this data is being read and written that often and it is not hundreds of MB in size, it will end up in the page cache, so you actually won't be reading and writing constantly from the SD card. That will just be synced periodically by the system.
Of course, if you want to ensure they are using RAM and not slower storage, and the information does not have to persist across reboots, put the file in
/tmp or another tmpfs backed location (you can see the existing ones with
mount | grep tmpfs). In case that is not clear, those are in RAM to start with.
Your one much more real issue will be concurrent access, so if you use files you will should implement file locking. On linux this is voluntary, meaning all parties need to implement it to work. The native system call is
man 2 flock; the
2 is important) which will have a wrapper version in most higher level languages; certainly python and php, anyway.
What [other] kinds of construct would fit for this?
There are lots of mechanisms for IPC; in this case shared memory segments jump to mind which may provide a performance advantage over file in memory, although again, since the load here is so tiny I doubt that will be meaningful. You might as well just use files (again, preferably ones with a tmpfs store, and make sure to use appropriate locking). Depending on the nature of what you are doing, you could also use a client-server style system with UNIX local sockets (which are supposedly a bit faster than inet sockets, but again, the volume here is I suspect so small it doesn't matter).
If it is just to indication a binary true/false status, you could use SysV semaphores, see
man sem_overview (I don't know what support there will be for this in js or php though).
The OS has various higher level messaging systems (e.g., d-bus) that may or may not be suited to what you are doing, but the more you get it that kind of thing the more complex it becomes and the sketchier support in some languages, I think particularly js, is going to become.