#3700 assigned enhancement

Add rtems_rate_monotonic_deadline()

Reported by: Sebastian Huber Owned by: Sebastian Huber
Priority: normal Milestone: 5.1
Component: rtems Version: 5
Severity: normal Keywords:
Cc: Blocked By:
Blocking:

Description (last modified by Sebastian Huber)

Depending on the scheduler selection, the rtems_rate_monotonic_period() behaves differently. In case the EDF scheduler is configured, then tasks using a rate-monotonic object have a higher priority (based on deadline) than the fixed priority background tasks. This is quite bad for applications which want to use the periods with a fixed priority just to get statistics and a deadline miss detection. The default SMP scheduler provides EDF functionality, so this is an issue while porting applications to SMP systems. To give applications more control, add a new function:

/**
 * @brief Starts a deadline and period.
 *
 * This routine starts a deadline and period.  In case Earliest Deadline First
 * (EDF) scheduling is available, then the priority of the executing task is
 * adjusted according to the specified deadline.  The next activation of the
 * executing task is specified by the period parameter.
 *
 * @param id The rate monotonic object identifier.
 * @param deadline The deadline in ticks.  Must be positive.
 * @param period The period in ticks.  Must be greater than or equal to the deadline.
 *
 * @retval RTEMS_SUCCESSFUL Successful operation.
 * @retval RTEMS_INVALID_ID No period objects exists for the specified object
 *   identifier.
 * @retval RTEMS_NOT_OWNER_OF_RESOURCE The period object belongs to another task.
 * @retval RTEMS_INVALID_NUMBER The deadline is zero or the period is less than the deadline.
 * @retval RTEMS_TIMEOUT The previous deadline was missed.
 */
rtems_status_code rtems_rate_monotonic_deadline(
  rtems_id       id,
  rtems_interval deadline,
  rtems_interval period
);

The new function uses two timing parameters to allow constrained deadlines and not only implicit deadlines.

The rtems_rate_monotonic_period() function should be changed to not alter the task priority depending on the implicit deadline. This avoids surprises while changing the scheduler to EDF in existing applications (especially while porting to an SMP system).

Change History (2)

comment:1 Changed on Feb 26, 2019 at 9:53:35 AM by Sebastian Huber

Description: modified (diff)

comment:2 Changed on Feb 26, 2019 at 12:40:41 PM by Sebastian Huber

What complicates the interface a bit is that rtems_rate_monotonic_deadline() is called after the current job is done (like rtems_rate_monotonic_period()) with parameters for the next job. This means that the constraint period >= deadline for the parameters makes no sense. The period should specify the time from the last activation to the next activation. The deadline should specify the time from the next activation to the deadline time point. The function checks that you have met the last deadline.

Note: See TracTickets for help on using tickets.