From: Kent Gibson <warthog618@gmail.com>
To: Sameh Mohamed <sameh4@gmx.com>
Cc: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>,
linux-gpio@vger.kernel.org
Subject: Re: [libgpiod] Question regarding locks / race conditions
Date: Mon, 17 Apr 2023 20:29:02 +0800 [thread overview]
Message-ID: <ZD07jv32RzLXKGfE@sol> (raw)
In-Reply-To: <CACMJSevuPg=bWkE5fTdechJMrTUWiaM9nn1f8G1tTDdphcPWFQ@mail.gmail.com>
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.
next prev parent reply other threads:[~2023-04-17 12:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABrMOxZY6Q3wiYsJUaXZiSET_gjMJ3GWaMrDCXwXC6nf7AX2_g@mail.gmail.com>
2023-04-17 7:19 ` [libgpiod] Question regarding locks / race conditions Bartosz Golaszewski
2023-04-17 12:29 ` Kent Gibson [this message]
[not found] ` <CABrMOxbWa8mxA=ckAu6QVKnej5o7UGrWXdeDMaAqScGVVk3=wA@mail.gmail.com>
2023-04-17 14:17 ` Kent Gibson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZD07jv32RzLXKGfE@sol \
--to=warthog618@gmail.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=sameh4@gmx.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).