lkml.org 
[lkml]   [2013]   [Nov]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5 2/4] MCS Lock: optimizations and extra comments
On Tue, Nov 19, 2013 at 02:57:41PM -0800, Tim Chen wrote:
> On Tue, 2013-11-19 at 11:13 -0800, Paul E. McKenney wrote:
> > On Fri, Nov 08, 2013 at 11:52:05AM -0800, Tim Chen wrote:
> > >
> > > +/*
> > > + * Releases the lock. The caller should pass in the corresponding node that
> > > + * was used to acquire the lock.
> > > + */
> > > static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *node)
> > > {
> > > struct mcs_spinlock *next = ACCESS_ONCE(node->next);
> > > @@ -51,7 +60,7 @@ static void mcs_spin_unlock(struct mcs_spinlock **lock, struct mcs_spinlock *nod
> > > /*
> > > * Release the lock by setting it to NULL
> > > */
> > > - if (cmpxchg(lock, node, NULL) == node)
> > > + if (likely(cmpxchg(lock, node, NULL) == node))
> >
> > Agreed here as well. Takes a narrow race to hit this.
> >
> > So, did your testing exercise this path? If the answer is "yes",
>
>
> Paul,
>
> I did some instrumentation and confirmed that the path in question has
> been exercised. So this patch should be okay.

Very good!

Thanx, Paul



\
 
 \ /
  Last update: 2013-11-20 00:21    [W:0.053 / U:0.244 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site