If resource usage isn't an issue, then the _easy_ thing to do, that would also be easily correct is to have a server doing all the h/w-related reading and clients talking to that server. Use for the server the technology you feel most confident with. Eg. you may use Python's http package. I believe that the server from this package runs in a single thread, and thus processes all requests synchronously. So, you'll get synchronization for free.
Then, the rest of the scripts that need to talk to h/w will instead be talking to this server. Again, this isn't an _efficient_ solution... but, sometimes you don't need one. And this one is easy to make, easy to debug, easy to expand. But, if instead you were looking for a more efficient solution, then, the general idea that allows the http server to work in this case would still apply: have a single synchronization program that takes requests asynchronously, and orders them. So, a basic TCP server would also work as well as a UNIX socket. Your idea with holding a lock on a file would also work (in fact, plenty of Linux utilities work that way, eg. apt-get or yum). ---- If you don't want to change the existing script, then instead of running them directly, you could run them through batch: https://man7.org/linux/man-pages/man1/batch.1p.html this is a very simply queuing program that's available for Linux. It will take care of synchronization by putting the scripts you want to run in a queue and executing them one at a time. On Sun, Jul 7, 2024 at 11:12 PM Chris Green via Python-list <python-list@python.org> wrote: > > I have a Raspberry Pi in my boat that uses I2C to read a number of > voltages and currents (using ADS1115 A2D) so I can monitor the battery > condition etc. > > At present various different scripts (i.e. processes) just read the > values using the I2C bus whenever they need to but I'm pretty sure > this (quite rarely) results in false readings because two processes > try to read at the same time. > > Thus I'm looking for ways to prevent simultaneous access. > > One fairly obvious way is to have single process/script which reads > the A2D values continuously and writes them to a file. All other > scripts then read from the file as needed, a simple file lock can then > be used to prevent simultaneous access (well, simultaneous access when > the writing process is writing). > > Is this the simplest approach? Are there better ways using > multiprocess? (They look more complicated though). > > The I2C bus itself has a mutex but I don't think this guarantees that > (for example) an A2D reading is atomic because one reading takes more > than one I2C bus access. > > Would a mutex of some sort around each I2C transaction (i.e. complete > A2D reading) be a better way to go? > > -- > Chris Green > · > -- > https://mail.python.org/mailman/listinfo/python-list -- https://mail.python.org/mailman/listinfo/python-list
