Feature Request: synchronous job release for periodic tasks

[Junjie Shi]

Currently, executing tasks in a periodic manner is supported by RTEMS through the usage of the rate monotonic manager. All further usage of the term periodicity complies with the definition in the RTEMS documentation chapter 11.2.3.

We’ve taken a look into the usage of periodic tasks with RTEMS and noticed, that mainly two functionalities are needed to realize periodic tasks for ones application:

1. rtems_rate_monotonic_create(…)
2. rtems_rate_monotonic_period(…) create(…) is used to create the control block for the period. period(…) actually starts and maintains the created period. This means the time of execution of a tasks first job and its following jobs is dependent on the first function call of period(…) and the specified period. The function call usually happens from within a tasks body (as it can be seen in the example from the RTEMS documentation chapter 11.3.7)

This implementation approach leads to the problem, that without additional action it is not possible to release multiple tasks synchronously. A synchronous release means that the first job of each intended task becomes available/arrives at the same time. This problem is caused by the the fact, that the first job of a higher priority task T1 delays the initialization of the period through calling period(…) in the first job of a lower priority task T2.

Nevertheless, in the research/teaching field as well as in practical applications, a synchronous release is often desired/used. Even though this problem could be avoided through a smart workaround on the level of application, we suggest that this feature of synchronous release should be implemented as part of the RTEMS rate monotonic manager. We propose, that the API should be extended such that a functionality becomes available, which allows the user to mark tasks for synchronous release while creating them. The first usage of period(…) to initialize the period would become redundant for these special cases, but would still work the same for all non-synchronized tasks.

One illustrative example has been attached, which shows that jobs are not released synchronously even if the release opertions are issued as early as possible. More details can be found in the comments in the attached source code.