[Bug 1636] Refactor Rate Monotonic Manager into a generic Periodic Manager

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1636

--- Comment #16 from Joel Sherrill <joel.sherrill at oarcorp.com> 2010-08-13 06:54:13 CDT ---
(In reply to comment #15)
> Maybe this should just be a renaming patch (if the renaming is OK) from
> rtems_rate_monotonic to rtems_periodic first.  Then we can attack how or if the
> supercore needs to be aware of periodic tasks.
> 
> My intuition is that the thread manager or scheduler should be aware if a task
> is periodic in nature, which indicates some aspect of periodic tasks should be
> in the supercore.  But I don't have a use case quite yet.
> 
> The justification for a separate rtems_periodic_xxx API remains that it makes
> it easier to use periodic tasks in non rate monotonic schedulers.

I am ok in concept with the patch as it is.  I haven't reviewed the current
version in detail yet though. Right now, the only API level objects implemented
in the score are threads but it may make sense for periods to be that way.
Remember the slide on SuperCore design/layering?

Without looking at the details, there are two ids needed: period id and
controlling thread id.  We already allow object ids as a "wait id" in the
Wait_Info for Threads.  But in this case, I think we may be better allowing
this to be a high level Score Object with Id.  The others are just APIs to
it.  If Rate Monotonic Periods just get added to the Period count in
confdefs.h,
I think this will work just fine.

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.