Darren Hart <dvh...@linux.intel.com> wrote on 2013/09/27 23:32:27:
>
> Re: Re: [PATCH] futex: Remove the owner check when waking task in
> handle_futex_death
>
> >
> > The earlier patch cannot solve another problem:
> > The owner wakes the next waiter through normal unlocking which make the
> > futex value as zero, the waked task exits before actually locking the mutex.
> > In this case, the owner doesn't call handle_futex_death() and the waked task
> > doesn't call futex_wake() when they are dying. The rest waiters will still
> > block as the same.
> >
> > This is also the reason that I drop the owner and FUTEX_WAITERS check,
> > because the futex value can be zero at that time.
> >
>
> If the FUTEX_WAITERS bit is not set, there are no waiters, and thus no
> need to wake. I understand why you dropped the OWNER check, but I'm not
> following this one. Where would the futex word be set from having
> waiters to zero when there might still be waiters pending?
>
>
> --
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
>
>
I have drawn a diagram as below:
process1 | process2
-------------------------------------------------------------
| thread1 | thread2 | thread3
-------------------------------------------------------------
t1|pthread_mutex_lock: | |
| __lock=self | |
| | |
t2| |pthread_mutex_lock:|
| |__lock|=FUTEX_WAITERS
| | syscall futex_wait|
| | |
t3| | |pthrea_mutex_lock:
| | |__lock|=FUTEX_WAITERS
| | | syscall futex_wait
| | |
t4|pthread_mutex_unlock:| |
| __lock=0 | |
| syscall futex_wake | waked |
| | |
t5| exit |exit: |
| | handle_futex_death|
---------------------------------------------------------------
t6| |pthread_mutex_lock:|
| |__lock=self|FUTEX_WAITERS
1, At time t4, in the unlocking process of glibc, it clears the FUTEX_WAITERS
bit before
calling futex_wake syscall.
2, At time t5, thread2 cannot know if the FUTEX_WAITERS bit was set.
3, Time t6 is expected but can never be true.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
