This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Optimal timing slice , Thread qn


my first question had nothing to do with the second one. I am sorry i
didnt make it clear in the email.
Regarding your comments: I am sure that the USART is receiving data as
I have seen the waveform on the scope. I have configured the serial
driver for the board.
I dont understand why cyg_io_write should block. it simply write a
character to USART without flow control. so if mutex is unlocked on
the USART it shall never block.
Anyhow the main question is that the cyg_io_write hogs all the cpu and
the cyg_io_read inspite of getting data is not running. I print out
the values after cyg_io_read and thats how I guess that its not
running.

Cheers


On Wed, 19 Jan 2005 06:55:05 -0700, Gary Thomas <gary@mlbassoc.com> wrote:
> On Tue, 2005-01-18 at 22:57 -0800, steve smith wrote:
> > Hey All
> > I got 2 more questions
> > 10 ms is the default time slice period per thread. Are there any
> > plots/metrics/graphs on the effect of size of this time slice on
> > various performance parameters. I would imagine having a too big a
> > slice is wasteful.... and too small a slice causes inefficient
> > frequent context switching. so probably a optima exists. How would one
> > gauge that?
> >
> > Also I have two thread at the same priority level one uses
> > cyg_io_read() to read from a USART and the other uses cyg_io_write()
> > to write to same USART. No flow control is used. The problem is that
> > if i don't put a delay at the end of them OR if i don't do
> > cyg_thread_yield() at the end, then only the cyg_io_write() thread is
> > run and the reading from USART doesn't take place. Both cyg_io_read
> > and cyg_io_write are protected by mutexes in their respective
> > threads.Why isn't the read thread ready for execution?.
> > thanks
> 
> It seems to me that this has nothing to do with time slices.
> Your read thread will block, i.e. not be ready to execute, until
> some data arrives at the UART and has been read.  Depending on
> how you've configured the system and which driver you are using,
> it might wait until "N" characters have arrived, or possibly a
> line ending character (e.g. "\n"), etc.  In the meantime, your
> writer thread can do whatever it wants until it also blocks.
> 
> What data is the write thread writing?  Where does it come from?
> How is that related to the reader thread?
> 
> In general, in a interrupt-driven system, threads only execute
> when they have something useful to do, in response to an interrupt
> or other event.  Do your threads not work this way?
> 
> --
> ------------------------------------------------------------
> Gary Thomas                 |
> MLB Associates              |  Consulting for the
> +1 (970) 352-4947           |    Embedded world
> http://www.mlbassoc.com/    |
> email: <gary@mlbassoc.com>  |
> gpg: http://www.chez-thomas.org/gary/gpg_key.asc
> ------------------------------------------------------------
> 
>

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]