This is the mail archive of the ecos-devel@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: [ECOS] periodic threads with kapi?


I'm struggling to see what is wrong with using an alarm, associated DSR and
a semaphore, and then simply looping on the semaphore in the periodic thread
as Nick suggested. I personally don't want to see extra code in the code
base unless it's absolutely necessary.

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________

> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Ryan Boder
> Sent: 19 August 2003 17:00
> To: Nick Garnett
> Cc: ecos-discuss@sources.redhat.com; ecos-devel@sources.redhat.com
> Subject: Re: [ECOS] periodic threads with kapi?
>
>
> On Tue, Aug 19, 2003 at 08:34:28AM +0100, Nick Garnett wrote:
> > > > This would be much cheaper in terms of overhead than using
> > > > cyg_thread_delay(). It also allows the alarm function to
> detect whether
> > > > the periodic thread has overrun.
> > >
> > > Why is there extra overhead? Isn't the delay function
> implemented with a
> > > thread timer that is an alarm?
> >
> > Each call to cyg_thread_delay() needs to set up the thread timer
> > object and install it in to the alarm list. Your own alarm can be set
> > up and installed only once. So you are moving work that needed to be
> > done on each cycle out to initialization code. All your thread has to
> > do is wait on the semaphore each time with no need to recalculate the
> > next wakeup. Everything else is handled by the alarm system.
>
> OK, I understand. I would like to have a convenient way to run periodic
> threads, as my primary interest in ecos right now is to have a
> GPL RTOS that
> I can use for my research, real-time software research topics are mostly
> about periodic threads and schedulability.
>
> So if I created a convenient way to do periodic threads in the manner you
> described above, could I contribute that back to ecos? If so should it be
> part of the kapi or just some library function that uses the kapi?
>
> --
> Ryan Boder
> http://www.bitwiser.org/icanoop
>
> --
> Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
> and search the list archive: http://sources.redhat.com/ml/ecos-discuss
>


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