Jan Kiszka wrote:
> Gilles Chanteperdrix wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Gilles Chanteperdrix wrote:
>>>>> GIT version control wrote:
>>>>>> Module: xenomai-jki
>>>>>> Branch: for-upstream
>>>>>> Commit: f1dfda551b6997f74141986759932e2723a9f024
>>>>>> URL:
>>>>>> http://git.xenomai.org/?p=xenomai-jki.git;a=commit;h=f1dfda551b6997f74141986759932e2723a9f024
>>>>>>
>>>>>> Author: Jan Kiszka <jan.kis...@siemens.com>
>>>>>> Date: Tue Mar 2 13:17:35 2010 +0100
>>>>>>
>>>>>> Native: Fix return code of in-kernel rt_cond_wait[_until]
>>>>>>
>>>>>> In rt_cond_wait_inner, do not let rt_cond_wait_epilogue overwrite the
>>>>>> primary error code of rt_cond_wait_prologue. This restores the in-kernel
>>>>>> semantics of rt_cond_wait[_until] that were valid before 97323b3287.
>>>>>>
>>>>>> Signed-off-by: Jan Kiszka <jan.kis...@siemens.com>
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> ksrc/skins/native/cond.c | 8 ++++----
>>>>>> 1 files changed, 4 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/ksrc/skins/native/cond.c b/ksrc/skins/native/cond.c
>>>>>> index 10727d1..2dc0069 100644
>>>>>> --- a/ksrc/skins/native/cond.c
>>>>>> +++ b/ksrc/skins/native/cond.c
>>>>>> @@ -472,10 +472,10 @@ static int rt_cond_wait_inner(RT_COND *cond,
>>>>>> RT_MUTEX *mutex,
>>>>>> err = rt_cond_wait_prologue(cond, mutex, &lockcnt,
>>>>>> timeout_mode, timeout);
>>>>>>
>>>>>> - if(!err || err == -ETIMEDOUT || err == -EINTR)
>>>>>> - do {
>>>>>> - err = rt_cond_wait_epilogue(mutex, lockcnt);
>>>>>> - } while (err == -EINTR);
>>>>>> + if (!err || err == -ETIMEDOUT || err == -EINTR) {
>>>>>> + while (rt_cond_wait_epilogue(mutex, lockcnt) == -EINTR)
>>>>>> + ; /* empty */
>>>>>> + }
>>>>> Not ok. If rt_cond_wait_epilogue returns an error other than -EINTR, we
>>>>> want this error to be returned.
>>>> As I said: This is what we used to do in 2.4 (and early 2.5-rc), and due
>>>> to the absence of spec on this topic, I would vote for restoring old
>>>> behavior.
>>> if rt_cond_wait_epilogue returns an error other than -EINTR, there is an
>>> error to be signaled, so, it should be returned to the user, not 0 or
>>> -ETIMEDOUT which would let the user think that he got the mutex back,
>>> whereas the mutex is probably not properly locked.
>> And if prologue returned -EINTR, and epilogue ran successfully, we do
>> not want to return -EINTR to the user either.
>
> We surely want as the cond_wait did NOT succeed in that case.
No, we do not know whether it succeeded, the condition may well have
been signaled while we no longer were waiting on the synch object. So,
we should return 0, and let the test the user must have in his code
decide whether the wakeup was spurious or not. In POSIX land, spurious
condition wake-up are permitted, I bet we want the same for the
rt_cond_wait interface. Which is why, BTW, all books on the pthread
interface recommend to use:
while (!cond)
pthread_cond_wait
and not:
if (!cond)
pthread_cond_wait
--
Gilles.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
