[ECOS] Question about cyg_flag_timed_wait()

[ECOS] Question about cyg_flag_timed_wait()

[Grant Edwards]

A colleague working on an eCos app is reporting that
cyg_flag_timed_wait() doesn't resume immediately when the flag
is set.  He says it won't resume until the next system tick
(which results in a delay of up to 10ms). So instead he uses
cyg_thread_delay() and cyg_thread_release() and claims that the
released thread starts immediately in that case.

I find it hard to believe that when an event flag is set,
waiting threads aren't resumed until the next timer tick, but I
haven't sifted through the kernel sources enough to say for
sure.

Can anybody who's more familiar with event flag implementation
comment?

-- 
Grant Edwards                   grante             Yow! With YOU, I can be
                                  at               MYSELF ...  We don't NEED
                               visi.com            Dan Rather ...


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Question about cyg_flag_timed_wait()

[Grant Edwards]

On 2009-11-02, Grant Edwards <grant.b.edwards@gmail.com> wrote:

> A colleague working on an eCos app is reporting that
> cyg_flag_timed_wait() doesn't resume immediately when the flag
> is set.  He says it won't resume until the next system tick
> (which results in a delay of up to 10ms). So instead he uses
> cyg_thread_delay() and cyg_thread_release() and claims that the
> released thread starts immediately in that case.

This "problem" seems to have come up again.  I've looked at the
event flag code, and I can't see how there could be a delay
when waking a thread using cyg_thread_setbits() and not when
waking a thread using cyg_thread_release().

Both cases just end up calling the target thread's wake()
method.  The only difference is that cyg_thread_release() calls
wake() unconditionally, and cyg_thread_setbits() only calls it
if the target thread is in the flag's waitqueue.

I'm not wrong am I?

-- 
Grant Edwards                   grante             Yow! What GOOD is a
                                  at               CARDBOARD suitcase ANYWAY?
                               visi.com            


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Question about cyg_flag_timed_wait()

[Bart Veer]

>>>>> "Grant" == Grant Edwards <grant.b.edwards@gmail.com> writes:

    Grant> On 2009-11-02, Grant Edwards <grant.b.edwards@gmail.com>
    Grant> wrote:
    >> A colleague working on an eCos app is reporting that
    >> cyg_flag_timed_wait() doesn't resume immediately when the flag
    >> is set. He says it won't resume until the next system tick
    >> (which results in a delay of up to 10ms). So instead he uses
    >> cyg_thread_delay() and cyg_thread_release() and claims that the
    >> released thread starts immediately in that case.

    Grant> This "problem" seems to have come up again. I've looked at
    Grant> the event flag code, and I can't see how there could be a
    Grant> delay when waking a thread using cyg_thread_setbits() and
    Grant> not when waking a thread using cyg_thread_release().

    Grant> Both cases just end up calling the target thread's wake()
    Grant> method. The only difference is that cyg_thread_release()
    Grant> calls wake() unconditionally, and cyg_thread_setbits() only
    Grant> calls it if the target thread is in the flag's waitqueue.

    Grant> I'm not wrong am I?

I have taken a look at this, and tried to reproduce it with a simple
testcase. I am afraid I cannot reproduce the problem: the
cyg_flag_timed_wait() always succeeds as soon as the flag is set. I
have also taken a look at the kernel code and can see no reason for
the reported behaviour.

The most obvious explanation is that it is a problem with thread
priorities. The cyg_flag_timed_wait() call may succeed as soon as the
flag is set, but the thread won't actually be resumed immediately if
there are higher-priority runnable threads, or if there is another
thread with the same priority which still has part of its timeslice to
run. For the latter scenario you would see something similar to what
you describe: some number of system clock ticks after the flag is set
the current thread's timeslice would expire, the other thread would be
resumed, and only then would the cyg_flag_timed_wait() appear to
return.

I would need a testcase before investigating any further.

Bart
    
-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Question about cyg_flag_timed_wait()

[Grant Edwards]

On 2010-01-02, Bart Veer <bartv@ecoscentric.com> wrote:

>    Grant> This "problem" seems to have come up again. I've looked at
>    Grant> the event flag code, and I can't see how there could be a
>    Grant> delay when waking a thread using cyg_thread_setbits() and
>    Grant> not when waking a thread using cyg_thread_release().
>
>    Grant> Both cases just end up calling the target thread's wake()
>    Grant> method. The only difference is that cyg_thread_release()
>    Grant> calls wake() unconditionally, and cyg_thread_setbits() only
>    Grant> calls it if the target thread is in the flag's waitqueue.
>
>    Grant> I'm not wrong am I?
>
> I have taken a look at this, and tried to reproduce it with a
> simple testcase. I am afraid I cannot reproduce the problem:
> the cyg_flag_timed_wait() always succeeds as soon as the flag
> is set. I have also taken a look at the kernel code and can
> see no reason for the reported behaviour.

I agree: I can't see any case where there would be any sort of
delay in the task being scheduled (assuming it would have
priority). 

> The most obvious explanation is that it is a problem with
> thread priorities. The cyg_flag_timed_wait() call may succeed
> as soon as the flag is set, but the thread won't actually be
> resumed immediately if there are higher-priority runnable
> threads, or if there is another thread with the same priority
> which still has part of its timeslice to run. For the latter
> scenario you would see something similar to what you describe:
> some number of system clock ticks after the flag is set the
> current thread's timeslice would expire, the other thread
> would be resumed, and only then would the
> cyg_flag_timed_wait() appear to return.
>
> I would need a testcase before investigating any further.

Thanks for looking at it -- I'm convinced that if there is a
delay in the task being scheduled it's an application code
issue with priorities.

-- 
Grant


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss