Re: [libgpiod] - fast writing while waiting for edge events

[Kent Gibson <warthog618@xxxxxxxxx>]

On Tue, Dec 12, 2023 at 02:01:51PM +0100, Mathias Dobler wrote:
> Hello Bartosz,
> I am writing a libgpiod 2 C# binding/abstraction for the dotnet
> community that I want to use personally. My use case is to monitor
> edge events from a hardware PWM signal, to react by reading some other
> GPIOs in a relatively short amount of time. This is likely a very
> specific use case but my goal is to make the binding cover as much
> uses cases as possible. And before searching for an alternative (like
> writing a kernel driver or so) I wanted to make sure I am not doing
> things wrong.
>

Don't top reply - reply inline instead.

I'm going to jump in here, as I think the thread safety documentation is
overly restrictive given the current implementation:

 * libgpiod is thread-aware but does not provide any further thread-safety
 * guarantees. This requires the user to ensure that at most one thread may
 * work with an object at any time. Sharing objects across threads is allowed
 * if a suitable synchronization mechanism serializes the access. Different,
 * standalone objects can safely be used concurrently. Most libgpiod objects
 * are standalone. Exceptions - such as events allocated in buffers - exist and
 * are noted in the documentation.

Firstly, as noted, if you are talking separate requests then they are
separate objects and you can do what you like.  So have one request for
your PWM edge generator and another for the lines to read/write.

But in practice even a single request would work.
While the documentation states you need to serialize access, that only
really applies if at least one of the accesses is a mutation.
In the current implementation, the gpiod_line_request object is immutable
so it is safe to access it from multiple threads.

Of course if two threads write to the same line at the same time that
would constitute a race, in the sense that you can't be sure
of they order they would write, but it is otherwise safe to do.

Finally, most libgpiod objects ARE mutable, so the documentation may be
restrictive to cover those.  Or it may be a defensive measure - in case
a future change makes a currently immutable object mutable.
It would be nice to have the gpiod_line_request documented as immutable,
as otherwise the safe option is to follow the contract in the
documentation and only access a particular libgpiod object from one thread
at a time, and for your use case to use separate requests.

Cheers,
Kent.

> Regards Mathias
>
> Am Di., 12. Dez. 2023 um 12:12 Uhr schrieb Bartosz Golaszewski <brgl@xxxxxxxx>:
> >
> > On Tue, Dec 12, 2023 at 10:55 AM Mathias Dobler <mathias.dob@xxxxxxxxx> wrote:
> > >
> > > Hello,
> > > From reading other conversations I've learned that it's not a good
> > > idea to have more than 1 thread accessing libgpiod objects. But this
> > > raises the question of how to react to events and let reads/writes
> > > through as quickly as possible at the same time. I have already played
> > > around with the file descriptor of the request object to interrupt the
> > > wait for edge events, but this solution is not good because it comes
> > > at the expense of responsiveness to events, and requires complicated
> > > synchronization.
> > > How bad would it be to have 1 thread waiting for events and 1 other
> > > thread reading/writing?
> > >
> > > Regards,
> > > Mathias
> > >
> >
> > Are you bitbanging? It totally sounds like bitbanging. Have you
> > considered writing a kernel driver for whatever you're doing?
> >
> > Bart