> On Wed, 16 Sep 2015, Zhu Jefferry wrote:
> > > > The primary debugging shows the content of __lock is wrong in first.
> > > > After a call of Mutex_unlock, the value of __lock should not be
> > > > this thread self. But we observed The value of __lock
> On Wed, 16 Sep 2015, Zhu Jefferry wrote:
> > The application is a multi-thread program, to use the pairs of
> > mutex_lock and mutex_unlock to protect the shared data structure. The
> > type of this mutex is PTHREAD_MUTEX_PI_RECURSIVE_NP. After running
> > long tim
> > I assume your pseudo code set_waiter_bit is mapped to the real code
> > "futex_lock_pi_atomic", It's possible for futex_lock_pi_atomic to
> > successfully set FUTEX_WAITERS bit, but return with Page fault, for
> > example, like fail in lookup_pi_state().
>
> No. It's not. lookup_pi_state() can
.@linutronix.de
> Subject: RE: [PATCH v2] futex: lower the lock contention on the HB lock
> during wake up
>
> On Tue, 15 Sep 2015, Zhu Jefferry wrote:
>
> Please configure your e-mail client proper and follow the basic rules:
>
> - Choose a meaningful subject for your qu
Hi
Just in the list, I see the patch "[PATCH v2] futex: lower the lock contention
on the HB lock during wake up" at
http://www.gossamer-threads.com/lists/linux/kernel/2199938?search_string=futex;#2199938.
But I see another patch with same name, different content here,
23b7776290b10297fe2c
5 matches
Mail list logo
