On Fri, Jan 17, 2020 at 4:03 PM Joel Sherrill <j...@rtems.org> wrote:
> > > On Fri, Jan 17, 2020 at 3:00 PM Gedare Bloom <ged...@rtems.org> wrote: > >> >> From the theory side, this problem is usually addressed using a >> (sporadic) server. Basically, you create some periodic task at the >> prioritization that you want (e.g., the shortest relative deadline in >> the system to usually get the highest priority) and then the server >> uses its budget to execute the event-based tasks. There are several >> variations with pros/cons. However, these do not allow for the >> event-based tasks to be the most responsive in general; with EDF, >> unless you use relative deadline = 1, there can always be some other >> task with a shorter absolute deadline. Also, if the server budget gets >> consumed you have to wait for replenishment. I'm not up-to-date with >> the latest in SMP schedulers with servers. (Shame on me.) >> > > I wondered about a band of high rate periodic tasks that check > for the condition and do it or go to sleep. Binds them to periods > which introduces latency so that's bad. > > This would work but likely not be acceptable. > A tickless scheduler would allow for a much finer scheduling quantum. At that point, an ISR could waken a task and hand it a new deadline. rtems_event_receive_periodic() combined with rtems_event_send_deadline()? Or perhaps some kind of rate_monotonic_interrupt_server? At least in my case, the task really is rate-monotonic, but the timing source is both asynchronous with respect to the kernel tick and much finer. -- Jonathan Brandmeyer
_______________________________________________ users mailing list users@rtems.org http://lists.rtems.org/mailman/listinfo/users
