All of lore.kernel.org
 help / color / mirror / Atom feed
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



  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.