mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michał Mirosław" <mirq-linux@rere.qmqm.pl>
To: Stephen Boyd <swboyd@chromium.org>
Cc: Doug Anderson <dianders@chromium.org>,
	Liam Girdwood <lgirdwood@gmail.com>,
	Mark Brown <broonie@kernel.org>,
	linux-kernel@vger.kernel.org, Dmitry Osipenko <digetx@gmail.com>
Subject: Re: [PATCH 6/6] regulator: core: simplify lock_two()
Date: Wed, 30 Aug 2023 19:25:22 +0200	[thread overview]
Message-ID: <ZO97gl1knsW8n99a@qmqm.qmqm.pl> (raw)
In-Reply-To: <CAE-0n531mK2Lvt7saXySPZLbGsA1giB3at0WDadErYOhcUv6ew@mail.gmail.com>

On Tue, Aug 29, 2023 at 05:57:31PM -0500, Stephen Boyd wrote:
> Quoting Michał Mirosław (2023-08-29 14:25:46)
> > On Tue, Aug 29, 2023 at 03:52:19PM -0500, Stephen Boyd wrote:
> > > Quoting Michał Mirosław (2023-08-28 13:26:54)
> > > > Indeed they are quite similar. I did remove a bit more code than that,
> > > > though: in this case there is no early success return before the loop.
> > > >
> > > > Instead of saying:
> > > >
> > > > lock A
> > > > lock B
> > > > if ok return
> > > > if that failed, loop:
> > > >   unlock A
> > > >   lock B harder
> > > >   lock A
> > > >   if ok return
> > > >   swap A <-> B
> > > >   lock B
> > > >
> > > > Now it's:
> > > >
> > > > lock A
> > > > loop forever:
> > > >   lock B
> > > >   if ok, return
> > > >   unlock A
> > > >   swap them
> > > >   lock A harder
> > > >
> > > > With the same condition 'A held' at the start of an iteration.
> > > >
> > >
> > > Removing duplicate code is great! I'm primarily concerned with
> > > readability. The terms 'A' and 'B' doesn't make it easy for me. Can you
> > > maintain the 'held' and 'contended' names for the variables?
> > >
> > > That would be
> > >
> > > 1.  lock 'held'
> > > 2.  loop forever:
> > > 3.    lock 'contended'
> > > 4.    if ok, return
> > > 5.    unlock 'held'
> > > 6.    swap them
> > > 7.    lock 'held' harder
> >
> > Doesn't this make it more confusing? The lock is 'held' only in lines
> > 2-5 and looses this trait (but not the name) on the other lines.
> > 'contended' is more problematic: the contended lock is called 'held'
> > before locking it at line 7.
> >
> > The algorithm is basically: Take the locks in sequence. If that failed,
> > swap the order and try again.
> >
> > Would a comment like the sentence above help with readability?
> >
> > Or we could wrap the final lines of the iteration in a
> > 'regulator_lock_contended()' to make it self-documenting?
> >
> 
> Squash this in?

I see that you prefer the held/contended intermediary names. I'd like to
understand why we differ in the perception of readability of this part
of code so that the change is needed? The algorithm is simple enough,
and it would work even if the locks weren't swapped for each iteration
(even if slower to finish). What is missing in the context of the
function's code? Are there some assumptions not easily visible?

BTW, I went on to add the regulator_lock_contended() to see how it
would look. I'll send a v2 with it so we can apply your proposal if
needed on top.

Best Regards,
Michał Mirosław

  reply	other threads:[~2023-08-30 18:36 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-19 22:46 [PATCH v2 0/6] regulator: core: locking fixes and cleanups Michał Mirosław
2023-08-19 22:46 ` [PATCH 2/6] regulator: core: skip nesting lock for -EDEADLK Michał Mirosław
2023-08-21 16:50   ` Doug Anderson
2023-08-19 22:46 ` [PATCH 1/6] regulator: core: simplify regulator_lock_nested() Michał Mirosław
2023-08-21 16:50   ` Doug Anderson
2023-08-19 22:46 ` [PATCH 3/6] regulator: core: simplify nested locking Michał Mirosław
2023-08-21 16:50   ` Doug Anderson
2023-08-28 21:01     ` Michał Mirosław
2023-08-19 22:46 ` [PATCH 4/6] regulator: core: remove `goto`s from resolve_supply() Michał Mirosław
2023-08-21 16:50   ` Doug Anderson
2023-08-19 22:46 ` [PATCH 5/6] regulator: core: propagate error out ouf regulator_lock_two() Michał Mirosław
2023-08-21 16:50   ` Doug Anderson
2023-08-19 22:46 ` [PATCH 6/6] regulator: core: simplify lock_two() Michał Mirosław
2023-08-21 16:51   ` Doug Anderson
2023-08-28 20:26     ` Michał Mirosław
2023-08-29 20:52       ` Stephen Boyd
2023-08-29 21:25         ` Michał Mirosław
2023-08-29 22:57           ` Stephen Boyd
2023-08-30 17:25             ` Michał Mirosław [this message]
2023-08-30 18:53               ` Stephen Boyd

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=ZO97gl1knsW8n99a@qmqm.qmqm.pl \
    --to=mirq-linux@rere.qmqm.pl \
    --cc=broonie@kernel.org \
    --cc=dianders@chromium.org \
    --cc=digetx@gmail.com \
    --cc=lgirdwood@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swboyd@chromium.org \
    /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

all inboxes | Powered by JetHome®