From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11492 invoked by alias); 19 Jun 2006 17:20:19 -0000 Received: (qmail 11477 invoked by uid 22791); 19 Jun 2006 17:20:17 -0000 X-Spam-Check-By: sourceware.org Received: from londo.lunn.ch (HELO londo.lunn.ch) (80.238.139.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 19 Jun 2006 17:20:13 +0000 Received: from lunn by londo.lunn.ch with local (Exim 3.36 #1 (Debian)) id 1FsNQ1-000813-00; Mon, 19 Jun 2006 19:20:09 +0200 Date: Mon, 19 Jun 2006 17:20:00 -0000 To: "Chase, Tom" Cc: ecos-discuss@ecos.sourceware.org Message-ID: <20060619172009.GD4218@lunn.ch> Mail-Followup-To: "Chase, Tom" , ecos-discuss@ecos.sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 From: Andrew Lunn X-IsSubscribed: yes Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] cyg_thread_delay vs cyg_flag_wait behavior X-SW-Source: 2006-06/txt/msg00169.txt.bz2 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