Messages in this thread | | | Date | Mon, 15 Nov 2004 02:01:48 +0000 | From | Jamie Lokier <> | Subject | Re: Futex queue_me/get_user ordering |
| |
Hidetoshi Seto wrote: > >So I don't know if NPTL is buggy, but the pseudo-code given in the bug > >report is (because of unconditional wake++), and so is the failure > >example (because it doesn't use a mutex). > > from glibc-2.3.3(RHEL4b2): > > 31 int > 32 __pthread_cond_signal (cond) > 33 pthread_cond_t *cond; > 34 { > 35 /* Make sure we are alone. */ > 36 lll_mutex_lock (cond->__data.__lock); > 37 > 38 /* Are there any waiters to be woken? */ > 39 if (cond->__data.__total_seq > cond->__data.__wakeup_seq) > 40 { > 41 /* Yes. Mark one of them as woken. */ > 42 ++cond->__data.__wakeup_seq; > 43 ++cond->__data.__futex; > 44 > 45 /* Wake one. */ > 46 lll_futex_wake (&cond->__data.__futex, 1); > 47 } > 48 > 49 /* We are done. */ > 50 lll_mutex_unlock (cond->__data.__lock); > 51 > 52 return 0; > 53 } > > Ingo, is this buggy? > > We should start again with a question: > Is this a kernel's bug or NPTL's bug?
Third possibility: your test is buggy. Do you actually use a mutex in your test when you call pthread_cond_wait, and does the waker hold it when it calls pthread_cond_signal?
If you don't use a mutex as you are supposed to with condvars, then it might not be a kernel or NPTL bug. I'm not sure if POSIX-specified behaviour is defined when you use condvars without a mutex.
If you do use a mutex (and you just didn't mention it), then the code above is not enough to decide if there's an NPTL bug. We need to look at pthread_cond_wait as well, to see how it does the "atomic" wait and mutex release.
-- Jamie - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |