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

[Kent Gibson <warthog618@xxxxxxxxx>]

On Wed, Dec 13, 2023 at 11:49:43AM +0100, Mathias Dobler wrote:
> Am Mi., 13. Dez. 2023 um 02:08 Uhr schrieb Kent Gibson <warthog618@xxxxxxxxx>:
>
> > Or are you using separate threads for lines within one request?
> > That is not what multi-line requests are intended for, and you would be
> > better off with separate requests for that case.
> > Multi-line requests are for cases where you need to read or write a set
> > of lines as atomically as possible - but you would do that from one
> > thread.  They can also be used where you only have a single thread
> > controlling several lines, so you only have to deal with the one request.
> > But if you want to independently control separate lines from separate
> > threads then separate requests is the way to go.

> I have one request object for 1 line 'req1' that's monitored (=wait
> and read edge_events) by 1 thread 't1'. At the same time,
> there lives another request object 'req2' for multiple lines, that's
> monitored by another thread 't2'. My use case is, that
> when t1 reads an edge event, it executes a callback that requires to
> read multiple values of 'req2'. Now the dilemma occurs.
> Does t1 interrupt t2 from waiting for edge events to gain the mutex,
> risking t2 missing edge events while t1 holds the mutex, or does
> t1 bypass the mutex and violate the libgpiod threading contract?
> I think this scenario could also be boiled down to a having only 1
> request for 1 line. Monitoring edge events, and at the same time
> trying to read/write or other performing other operations on the
> request object would result in the same dilemma.
> Again, this might just be a a very specific use case with strong time
> constraints (that I wish libgpiod supported out of the box).
>

Firstly note that you cannot lose edge events. They are queued in the
kernel in case userspace is a bit busy.  It is still possible to overflow
the queue, but it takes serious effort.  You can check the seqnos in the
events to detect an overflow.

It is also a bit odd to be monitoring a line for edges AND polling it
at the same time.  You get edge events when it changes value, so polling
between edges is redundant.

I suggest not holding the mutex while waiting, only reading.
Holding a mutex while waiting is generally poor form.  Use a structural
mechanism to prevent the requests being closed while threads are waiting
on them. e.g. cancel the wait before performing the release.

Though if you are using a libgpiod function to perform the wait you are
still stuck, as going by the documentation you have to prevent other
access while you are waiting....

So you have to not use a libgpiod function and wait by poll()ing the
request fd.
At that point you may as well wait on both requests in the one thread.
And then you don't need the mutex as you only have one thread accessing the
requests.

Cheers,
Kent.