Notice: We have migrated to GitLab launching 2024-05-01 see here:

#3700 assigned enhancement

Add rtems_rate_monotonic_deadline()

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

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 (7)

comment:1 Changed on 02/26/19 at 09:53:35 by Sebastian Huber

Description: modified (diff)

comment:2 Changed on 02/26/19 at 12:40:41 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.

comment:3 Changed on 12/13/19 at 14:30:05 by Joel Sherrill

Milestone: 5.16.1

Pushing to 6.1. This is a recent ticket requesting an enhancement and should not block a 5 release.

comment:4 Changed on 06/29/20 at 21:18:44 by Jonathan Walsh

We are seeing a behavior with EDF enabled in SMP mode that we see a hang under load. The test stimulus that we have isolated this to is now very simple.

for(uint32_t j = 0; j < test_iterations; j++)

sc = pthread_mutex_lock(&mx);
rtems_test_assert(sc == RTEMS_SUCCESSFUL);
sc = pthread_mutex_unlock(&mtx);
rtems_test_assert(sc == RTEMS_SUCCESSFUL);


When we run this pretty much basic unit test all OK. Then we run more and more threads in parallel and we see RTEMS lock up. When we go to the simple round-robin scheduler we can run these loops forever with as many threads as we want and don't see a lock-up.

Apologies if I am posting the question in the wrong place - I want to avoid creating spam. Sebastian seems to be the expert on EDF and we are wondering if this is a known issue with a lock-up under load with EDF enabled.

comment:5 in reply to:  4 Changed on 06/30/20 at 05:09:02 by Sebastian Huber

Replying to Jonathan Walsh:

Apologies if I am posting the question in the wrong place - I want to avoid creating spam. Sebastian seems to be the expert on EDF and we are wondering if this is a known issue with a lock-up under load with EDF enabled.

I moved this issue to a new ticket: #4019.

comment:6 Changed on 06/18/21 at 09:24:45 by Sebastian Huber

Keywords: qualification added

comment:7 Changed on 11/19/21 at 14:45:12 by Sebastian Huber

Milestone: 6.17.1
Note: See TracTickets for help on using tickets.