From 60a6d6eae95ad49b9ddf53c6767f22aa4b3897a2 Mon Sep 17 00:00:00 2001 From: Sebastian Huber Date: Thu, 9 Nov 2017 10:22:24 +0100 Subject: Change RTEMS version to 5 Update #3220. --- c-user/key_concepts.rst | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) (limited to 'c-user/key_concepts.rst') diff --git a/c-user/key_concepts.rst b/c-user/key_concepts.rst index 52e416c..3d1a473 100644 --- a/c-user/key_concepts.rst +++ b/c-user/key_concepts.rst @@ -258,7 +258,7 @@ only available in SMP configurations and replaces the priority inheritance protocol in this case. One aim of the locking protocols is to avoid priority inversion. -Since RTEMS 4.12, priority updates due to the locking protocols take place +Since RTEMS 5.1, priority updates due to the locking protocols take place immediately and are propagated recursively. The mutex owner and wait for mutex relationships define a directed acyclic graph (DAG). The run-time of the mutex obtain, release and timeout operations depend on the complexity of this @@ -314,7 +314,7 @@ Priority Inheritance Protocol The priority of the mutex owner is raised to the highest priority of all threads that currently wait for ownership of this mutex :cite:`Sha:1990:PI`. -Since RTEMS 4.12, priority updates due to the priority inheritance protocol +Since RTEMS 5.1, priority updates due to the priority inheritance protocol take place immediately and are propagated recursively. .. _MrsP: @@ -334,7 +334,7 @@ then the normal priority of the thread is restored. Threads that wait for mutex ownership are not blocked with respect to the scheduler and instead perform a busy wait. The MrsP uses temporary thread migrations to foreign scheduler instances in case of a preemption of the mutex owner. This locking -protocol is available since RTEMS 4.11. It was re-implemented in RTEMS 4.12 to +protocol is available since RTEMS 4.11. It was re-implemented in RTEMS 5.1 to overcome some shortcomings of the original implementation :cite:`Catellani:2015:MrsP`. @@ -353,7 +353,7 @@ OMIP mutexes do not need any external configuration data, e.g. a ceiling priority. This makes them a good choice for general purpose libraries that need internal locking. The complex part of the implementation is contained in the thread queues and shared with the MrsP support. This locking protocol is -available since RTEMS 4.12. +available since RTEMS 5.1. Thread Queues ============= @@ -406,7 +406,7 @@ In case the thread is dequeued, there are two options Since there are usually more objects than threads, this actually reduces the memory demands. In addition the objects only contain a pointer to the queue structure. This helps to hide implementation details. Inter-cluster priority -queues are available since RTEMS 4.12. +queues are available since RTEMS 5.1. A doubly-linked list (chain) is used to implement the FIFO queues yielding a :math:`O(1)` worst-case time complexity for enqueue and dequeue operations. @@ -480,9 +480,9 @@ The use cases fall roughly into two categories: and need a high resolution. An example use case is a time driven scheduler, e.g. rate-monotonic or EDF. -In RTEMS versions prior to 4.12 the timer and timeout support was implemented +In RTEMS versions prior to 5.1 the timer and timeout support was implemented by means of delta chains. This implementation was unfit for SMP systems due to -several reasons. The new implementation present since RTEMS 4.12 uses a +several reasons. The new implementation present since RTEMS 5.1 uses a red-black tree with the expiration time as the key. This leads to :math:`O(log(n))` worst-case insert and removal operations for :math:`n` active timer or timeouts. Each processor provides its own timer and timeout service -- cgit v1.2.3