From: Andrew Lunn <andrew@lunn.ch>
To: "Chase, Tom" <tomc@dtccom.com>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] cyg_thread_delay vs cyg_flag_wait behavior
Date: Mon, 19 Jun 2006 17:20:00 -0000 [thread overview]
Message-ID: <20060619172009.GD4218@lunn.ch> (raw)
In-Reply-To: <F7F756E5ED50F345959AE893AD2F156608C6EA@dtcsrvr09.dtccom.com>
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
next prev parent reply other threads:[~2006-06-19 17:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-19 13:07 Chase, Tom
2006-06-19 17:20 ` Andrew Lunn [this message]
2014-10-17 15:14 Leschke Serafin (lesc)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060619172009.GD4218@lunn.ch \
--to=andrew@lunn.ch \
--cc=ecos-discuss@ecos.sourceware.org \
--cc=tomc@dtccom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).