On Sun, 24 Nov 2019 10:14:38 +0100, "R.Wieser" 
declaimed the following:

>
>Yes, and no.   That kind of behaviour is pretty-much a requirement for
>accessing hardware in a multi-tasking environment.  Don't do it and the
>first time two programs want to use the same hardware you get (either soft
>or hardware) sparks flying all around.   So I /expect/ it to be there - but
>do not know for certain.
>

 Except for the minor facet that Linux treats /everything/ as a /file/
-- and files don't have commonly have inherent mutex locking. That includes
pretty much everything in /dev

https://stackoverflow.com/questions/15762752/exclusively-open-a-device-file-in-
linux/54808819

 If one has the privilege to open the device file, anything goes. In
early releases of the OS, one had to run programs using sudo in order to
access GPIO pins -- they've since tended to add a "gpio" group, give the
user "gpio" group membership, and tied the pins to the group for access.

 One doesn't normally have privileges to access, say, a printer
"device"; instead "printing" involves generating a data file of the print
"image", and that file is submitted to a spooler daemon -- the daemon has
access to the printer device, and it is responsible for only feeding one
spooled file at a time to it.

 This is the equivalent of a method you've already rejected -- creating
a protocol your multiple applications will use to submit requests to a
daemon, and the daemon then does all the actual I2C processing. Such a
protocol would have to encapsulate entire transactions as one unit. {This
will show up a bit later in this reply, in the context of existing
features.}

 
>> Have you tried a search for "Linux share i2c"?
>
>Yes, I have.  Exactly two seconds ago.  :-)   And thanks for that.  I've
>(ofcourse) first tried to google something myself, but couldn't think of the
>right keyword combination (got stuck on "multiple programs").
>

 The other candidate would be "concurrent".

>
>Ehrmm...  That is not what the links you posted seem to tell me ...
>

 As I understand, you don't have to worry about two I2C operations
interfering with each other... BUT

 Most actions to read from some device (a 3-axis MEMS sensor, say)
require TWO I2C operations. First one performs a WRITE operation to specify
to the device what internal data registers are going to be requested. On
then performs a READ operation to actually fetch that data.

 There is nothing that I've seen that would prevent a second process
from doing a WRITE of its own to the device specifying a different register
to be read.

WRITE request X data
      WRITE request Y data
READ (gets Y instead of X)
      READ (who knows what gets returned*)


* For a device with X, Y, Z; many of them will "increment" the register
so instead of

write request X
read X
write request Y
read Y
write request Z
read Z

one just does

write request X
read X
read Y
read Z

 Locking so that the WRITE and READ occur before another process can get
an operation on the device is not inherent. For this MEMS sensor, that
means locking it for between 4 [the incrementing mode] and 6 separate
[explicit request mode] operations.

 When the two processes are accessing different devices (different bus
or same bus different address), there is no conflict -- the state of the
device is not affected between the WRITE and READ from a process,
regardless of what the other process does between them. The driver ensures
that one operation is performed before the next gets on the bus.



--
 Wulfraed                 Dennis Lee Bieber         AF6VN
 wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

--- SoupGate-Win32 v1.05