Re: [ECOS] cyg_thread_delay vs cyg_flag_wait behavior

[Andrew Lunn <andrew at lunn dot ch>]

On Mon, Jun 19, 2006 at 09:07:26AM -0400, Chase, Tom wrote:
> Hello,
> 
> I am working on my fourth ecos project.  Historically I have had a thread
> monitoring a serial port.  The thread has the lowest priority and sits at a
> getc until some data arrives then deals with it.  This has worked well for
> debugging and configuration allowing a PC application to talk to the device
> and set up frequencies or what not.
> 
> On the latest project this isn't working reliably.  It will work for a few
> bytes of data then stop responding.  The change in performance appears to be
> related to cyg_thread_delay vs. cyg_flag_wait.  For the first time, I have a
> higher priority thread that has no cyg_thread_delays in it.  It sits at a
> cyg_flag_wait most of the time (servicing flags every 100 to 250 ms).  If I
> add a cyg_thread_delay to that thread (putting it just before the flag_wait
> for example) then the serial behavior is as I expect.
> 
> I am working on an OMAP5912 and using the interrupt driven serial.  I have
> verified that the thread is indeed waking up from the wait as I expect (10
> times a second) and not always running (I.E. there is time available for
> lower priority threads).  I have tried using various settings (buffered, non
> buffered, stdin, TTY etc.) with no change in performance.  I have a
> cyg_thread_delay that is called when the unit prepares to power down (to
> lock out the keyboard) and any buffered serial inputs are handled then
> (which is one clue to why this was happening).
> 
> I can add a delay but I would like to understand the differences between
> these two functions while they are blocking.  Conceptually I think of the
> delay and the wait doing the same thing and do not understand why they
> behave differently while they are in effect.  Can anyone advise?  

It sounds like the thread that is waiting is actually spinning inside
the wait function. From the sources:

    // this loop allows us to deal correctly with spurious wakeups
    while ( result && (0 == saveme.value_out) ) {
        self->set_sleep_reason( Cyg_Thread::WAIT );
        self->sleep();
        // keep track of myself on the queue of waiting threads
        queue.enqueue( self );

        // Allow other threads to run
        Cyg_Scheduler::reschedule();

So there is a while loop there making a spin possible. I would take a
closer look at this and see if it really is spinning rather than
sleeping, and if so why.

          Andrew

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