Dennis,

>>Yes, and no.   That kind of behaviour is pretty-much a requirement
>> for accessing hardware in a multi-tasking environment.
...
> Except for the minor facet that Linux treats /everything/ as a /file/
> -- and files don't have commonly have inherent mutex locking.

Which means its good I asked. :-)

But that raises the question about what I should think about whats in the
third link you posted (i2c-concurrent-access-on-linux-mutex), which seems to
indicate its present - and on a low level too.

> and that file is submitted to a spooler daemon
...
> This is the equivalent of a method you've already rejected

I didn't (intend to) reject the gatekeeper method itself, just the part
where the communication with it is supposed to be done by the user "through
some protocol".    I would like to create/see an API, preferrably shadowing
an existing I2C one.

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

That is the problem I tried to explain in my "lightbulb moment" paragraph.
Although I referred to the I2C signals themselves (the "start" and "stop"
ones) I also assumed that those signals would coincide with the locking and
unlocking of the I2C bus (or the other way around).

In other words, I was coining up the possibility of an atomic write-read
sequence (by not ending the write sequence with a "stop" condition, but
sending another "start" instead).    It would solve most, if not all of the
interference problems.

The only question is if that has already been implemented, or if I need
to/can do it myself.

Regards,
Rudy Wieser

--- SoupGate-Win32 v1.05