This is the mail archive of the
mailing list for the eCos project.
Re: [ECOS] periodic threads with kapi?
- From: Ryan Boder <icanoop at bitwiser dot org>
- To: Nick Garnett <nickg at ecoscentric dot com>
- Cc: ecos-discuss at sources dot redhat dot com, ecos-devel at sources dot redhat dot com
- Date: Tue, 19 Aug 2003 12:00:26 -0400
- Subject: Re: [ECOS] periodic threads with kapi?
- References: <20030817140013.GA27112@bitwiser.org> <20030817184316.89A1EEC758@delenn.bartv.net> <20030818040523.GA30591@bitwiser.org> <20030818085318.7E7B1EC758@delenn.bartv.net> <email@example.com> <20030819042825.GA3117@bitwiser.org> <firstname.lastname@example.org>
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?