Re: [libgpiod] Question regarding locks / race conditions

Re: [libgpiod] Question regarding locks / race conditions

[Bartosz Golaszewski]

On Sun, 16 Apr 2023 at 18:20, Sameh Mohamed <sameh4@gmx.com> wrote:
>
> Hello,
>
> Many thanks for your excellent work and contributions.  I've been learning about libgpiod in the last few days.
>
> Studying the cxx bindings examples, particularly around line request, I looked up the C code for gpiod_line_request_get_values_subset  and saw that it does not deal with any potential locks.
>
> I searched a bit on stackoverflow regarding Linux device drivers, and saw that it's basically up to the application to manage locks.
>
> As an inexperienced programmer in the Linux user-space; I have worked primarily in python and C++ client applications at a higher level, I wanted to confirm my understanding.  If I am writing some library to run the RaspberryPi that will make use of libgpiod-2.0.1, it will be up to me to avoid locks when making line requests, etc.
>
> Thanks,
> Sameh

Yes! It's a design approach low-level C libraries usually take and
libgpiod is no exception.

Bart

Re: [libgpiod] Question regarding locks / race conditions

[Kent Gibson]

On Mon, Apr 17, 2023 at 09:19:31AM +0200, Bartosz Golaszewski wrote:
> On Sun, 16 Apr 2023 at 18:20, Sameh Mohamed <sameh4@gmx.com> wrote:
> >
> > Hello,
> >
> > Many thanks for your excellent work and contributions.  I've been learning about libgpiod in the last few days.
> >
> > Studying the cxx bindings examples, particularly around line request, I looked up the C code for gpiod_line_request_get_values_subset  and saw that it does not deal with any potential locks.
> >
> > I searched a bit on stackoverflow regarding Linux device drivers, and saw that it's basically up to the application to manage locks.
> >
> > As an inexperienced programmer in the Linux user-space; I have worked primarily in python and C++ client applications at a higher level, I wanted to confirm my understanding.  If I am writing some library to run the RaspberryPi that will make use of libgpiod-2.0.1, it will be up to me to avoid locks when making line requests, etc.
> >
> > Thanks,
> > Sameh
> 
> Yes! It's a design approach low-level C libraries usually take and
> libgpiod is no exception.
> 

Just to add my 2c...

It isn't clear to me where you expect that locks need to be applied.

Single threaded apps, such as the examples, do not require any locks.
Similarly apps that restrict a given line request to a single thread.
Any shared resources within the kernel, including the relevant device
drivers, are handled by the kernel.

The GPIO uAPI provided by the kernel, and that libgpiod wraps, is MT-safe
(though I can't think of a use case where making calls on a given line request
concurrently from multiple threads is a good idea).

However, data structures returned by libgpiod are in userspace and are not
MT-safe.  So if you want to share those structures between threads then
you need to add locking to prevent potential race conditions.
As Bart alluded to above, the best way to do that is dependent on the
application, so low-level libraries like libgpiod usually leave it to the
app.

And again, you probably don't want to share a line request between
threads anyway - even if you think you do.

Cheers,
Kent.

Re: [libgpiod] Question regarding locks / race conditions

[Kent Gibson]

On Mon, Apr 17, 2023 at 10:13:18AM -0400, Sameh Mohamed wrote:
> Thanks Kent and Bartosz,
> 
> @Kent: you are correct, I don't intend to share any line requests on the
> same line, rather I am curious what will happen if two threads create two
> requests for two lines at the same time.  For instance two threads setting
> values on different GPIO pins but at the same time.
> 

No locks necessary - the kernel will deal with any resource contention
internally.

Cheers,
Kent.