Article <mailman.22.1720443071.2981.python-list@python.org>

Deutsch English Français Italiano
<mailman.22.1720443071.2981.python-list@python.org>

View for Bookmarking (what is this?)
Look up another Usenet article
Path: ...!2.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!not-for-mail
From: Left Right <olegsivokon@gmail.com>
Newsgroups: comp.lang.python
Subject: Re: Best (simplest) way to share data between processes
Date: Sun, 7 Jul 2024 23:55:09 +0200
Lines: 65
Message-ID: <mailman.22.1720443071.2981.python-list@python.org>
References: <9a8nlk-jb81.ln1@q957.zbmc.eu>
 <CAJQBtgn3t+ADURKODqMc3BDoK9v_1hP098AXxi0_JeLqWSAAHg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cancel-Lock: sha1:k0bi5e2EGfmF2e+S3hx42xx7Zzk= sha256:cDWinOQVMOtO7rBi67s9uNH+9BSjXBqrlnMIUQkpPJY=
In-Reply-To: <9a8nlk-jb81.ln1@q957.zbmc.eu>
Precedence: list
Bytes: 8631

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=E2=80=AFPM 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
> =C2=B7
> --
> https://mail.python.org/mailman/listinfo/python-list