From: Jason Low <jason.low2@hp.com>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>,
mingo@kernel.org, akpm@linux-foundation.org,
linux-kernel@vger.kernel.org, paulmck@linux.vnet.ibm.com,
tim.c.chen@linux.intel.com, peter@hurleysoftware.com,
riel@redhat.com, hpa@zytor.com, walken@google.com,
davidlohr@hp.com, Waiman.Long@hp.com, aswin@hp.com,
scott.norton@hp.com, chegu_vinod@hp.com
Subject: Re: [RFC PATCH 1/3] locking/mutex: Try to acquire mutex only if it is unlocked
Date: Wed, 04 Jun 2014 15:13:31 -0700 [thread overview]
Message-ID: <1401920011.2232.49.camel@j-VirtualBox> (raw)
In-Reply-To: <alpine.DEB.2.10.1406042337110.18296@nanos>
On Wed, 2014-06-04 at 23:54 +0200, Thomas Gleixner wrote:
> On Wed, 4 Jun 2014, Jason Low wrote:
> > On Wed, 2014-06-04 at 21:43 +0200, Peter Zijlstra wrote:
> > > > /*
> > > > * A negative mutex count indicates that waiters are sleeping waiting for the
> > > > - * mutex.
> > > > + * mutex, and a count of one indicates the mutex is unlocked.
> > > > */
> > > > #define MUTEX_SHOW_NO_WAITER(mutex) (atomic_read(&(mutex)->count) >= 0)
> > > > +#define MUTEX_IS_UNLOCKED(mutex) (atomic_read(&(mutex)->count) == 1)
> > >
> > > So I recently saw that MUTEX_SHOW_NO_WAITER thing and cried a little;
> > > and now you're adding more of that same nonsense.
> > >
> > > Please make them inline functions, also can we rename the SHOW_NO_WAITER
> > > thing, because its not at all clear to me wtf it does; should it be
> > > called: mutex_no_waiters() or somesuch?
> >
> > Okay, I can make them inline functions. I mainly added the macro to keep
> > it consistent with the MUTEX_SHOW_NO_WAITER() check, but we can surely
>
> Consistency with a digusting and nonsensical macro is not really a
> good argument.
I agree :)
> > make this more clear. mutex_no_waiters() sounds fine, or perhaps
> > something like mutex_has_no_waiters()?
>
> Uuurg. So we end up with
>
> if (!mutex_has_no_waiters(m))
>
> if we check for waiters?
>
> Can we please go with the most intuitive thing:
>
> mutex_has_waiters()
>
> and have the callsites prepend the '!' in case they want to check
> there is no waiter?
Yes, !mutex_has_waiters() sounds like the better option to check for no
waiters. Same with using the already provided mutex_is_locked()
function.
> For heavens sake, we do not name macros/inlines in a way which fits
> the intended use case. We name them so they make sense.
>
> Your change log blurbs about readability. I have no idea what your
> understandig of readability is, but neither MUTEX_SHOW_NO_WAITERS nor
> mutex_has_no_waiters qualify for me. Ditto for MUTEX_IS_UNLOCKED.
>
> Care to look at the other lock implementations:
>
> rt_mutex_has_waiters()
> spin_is_locked()
> ....
>
> Why would it make sense to come up with reverse conventions for mutex?
>
> Thanks,
>
> tglx
Thanks,
Jason
next prev parent reply other threads:[~2014-06-04 22:13 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-04 19:08 [RFC PATCH 0/3] locking/mutex: Modifications to mutex Jason Low
2014-06-04 19:08 ` [RFC PATCH 1/3] locking/mutex: Try to acquire mutex only if it is unlocked Jason Low
2014-06-04 19:43 ` Peter Zijlstra
2014-06-04 20:57 ` Davidlohr Bueso
2014-06-04 20:58 ` Davidlohr Bueso
2014-06-09 17:38 ` Jason Low
2014-06-11 21:00 ` Long, Wai Man
2014-06-11 21:48 ` Jason Low
2014-06-12 1:25 ` Long, Wai Man
2014-06-04 21:53 ` Jason Low
2014-06-04 21:26 ` Jason Low
2014-06-04 21:54 ` Thomas Gleixner
2014-06-04 22:13 ` Jason Low [this message]
2014-06-05 3:24 ` Waiman Long
2014-06-05 19:21 ` Jason Low
2014-06-04 19:08 ` [RFC PATCH 2/3] locking/mutex: Correct documentation on mutex optimistic spinning Jason Low
2014-06-04 20:11 ` Davidlohr Bueso
2014-06-04 20:30 ` Jason Low
2014-06-04 19:08 ` [RFC PATCH 3/3] locking/mutex: Optimize mutex trylock slowpath Jason Low
2014-06-04 20:28 ` Davidlohr Bueso
2014-06-04 21:47 ` Jason Low
2014-06-05 1:10 ` Davidlohr Bueso
2014-06-05 3:08 ` Jason Low
2014-06-04 20:13 ` [RFC PATCH 0/3] locking/mutex: Modifications to mutex Davidlohr Bueso
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=1401920011.2232.49.camel@j-VirtualBox \
--to=jason.low2@hp.com \
--cc=Waiman.Long@hp.com \
--cc=akpm@linux-foundation.org \
--cc=aswin@hp.com \
--cc=chegu_vinod@hp.com \
--cc=davidlohr@hp.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=paulmck@linux.vnet.ibm.com \
--cc=peter@hurleysoftware.com \
--cc=peterz@infradead.org \
--cc=riel@redhat.com \
--cc=scott.norton@hp.com \
--cc=tglx@linutronix.de \
--cc=tim.c.chen@linux.intel.com \
--cc=walken@google.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.