• We want to have real processes with separate threads of control
• But we also want to be able to analyse the schedulability of the program to ensure deadlines are met
• Ravenscar is a set of restrictions on Ada which together limit the concurrency features in such a way that analysis is possible
• Ravenscar is only concerned with concurrency analysis – it does not have any opinion on the sequential parts of the program

In this article, I'm going to use the term processes, which in terms of Ada means "tasks and protected objects" – the concurrency mechanisms used by Ravenscar.

Ravenscar guarantees that

• The set of independent processes and interrupts is fixed and constant after program elaboration by
  • Only allowing creation of processes in the declarative part of library-level packages (the number of processes cannot increase during run-time)
  • Forbidding termination of processes (the number of processes cannot decrease during run-time)
    • however, what happens if a task actually terminates is implementation-defined
    • for example, with GNAT, task termination under Ravenscar counts as "erroneous execution" which is frighteningly similar to "undefined behaviour" in CC
  • Forbidding run-time changes to priorities and interrupt handlers
• Synchronisation and communication between processes happen only through protected objects and suspension objects by
  • Forbidding select statements and entries in tasks
• The program has deterministic memory usage by
  • Forbidding implicit heap allocations
• There is a deterministic execution model by
  • Only allowing one entry for each protected object, which prevents non-determinism caused by multiple open entries and choosing which is served first
  • Only allowing one process to block at that entry, preventing non-determinism caused by differing queue lengths
  • Only allowing simple barriers (i.e. a single boolean variable) which reduces variability in execution time of the barrier
  • Forbidding relative delays, which are trouble if a process is preempted after calculating the relative delay, but before actually suspending at the delay
  • Only allowing delays to be calculated using the high-precision Ada.Real_Time library
  • Forbidding potentially blocking calls in protected subprograms; these are primarily
    • task entry calls
    • delay statements
    • language-standard defined operations like file I/O

• In standard Ada, tasks are started as part of program elaboration, not after it
  • This means a task or interrupt handler can start running before the full program is initialised
    • Thus, an unfortunate processs may read, e.g., a global constant that has not yet been initialised
• To solve this, the Ada standard is revised to include the pragma Partition_Elaboration_Policy (Sequential)
  • This pragma simply makes sure non-environment processes are not started until the program is otherwise fully elaborated

I won't copy and paste the example code both because it's superfluous and because I don't know copyright law well enough. I'll share some of my takeaways though.

• Cyclic tasks with precedence
  • Imagine a set of tasks X, Y and Z in decreasing priority, such that X has the highest priority and Z the lowest
  • None of the tasks peform any blocking operation, and they all have relatively short deadlines (say, 20 milliseconds, in our example)
  • All three tasks read a common "start time" from a protected object
  • All three tasks delay until (Start_Time + Milliseconds (2000))
  • Then, technically, the execution on a monoprocessor should always be first X, then Y, then Z in short succession, followed by the program idling for roughly two seconds, and then it repeats
• Event-triggered tasks
  • Sit in a loop, and at the beginning of the loop they wait on an entry or suspension object
  • Once they are released by that entry or suspension object, they perform their action associated with the event
  • If they need to know more about the event to run, they should wait at a protected entry
• Priority of protected objects
  • Protected objects must have a priority ceiling higher than any of the calling tasks
    • This prevents deadlocking where the task is waiting for a protected object that is not allowed to resume because it has a lower priority than the task waiting for it
    • The default priority is System.Priority'Last which works but may be unnecessarily high and cause other high-priority tasks to miss deadlines they would otherwise meet
  • Suspension objects vs. protected entries
    • Both are used for synchronisation
    • Protected entries can communicate data as part of this synchronisation (in other words, protected entries can have out parameters)
    • Protected entries can also execute other (non-blocking) code as part of the signalling operation
    • Suspension objects do not have parameters and cannot execute code – synchronisation is all they do
• Two protected entries
  • Useful e.g. to read and write from a buffer – we want to block writes if the buffer is full, and block reads if the buffer is empty
  • Use two protected objects (e.g. one for reading and one for writing)
  • They signal each other with regular procedures when they need to start blocking
  • They allow external code to wait on each

These are my own "big take-away points" from the guide. I hope these capture a decent intuition for what Ravenscar is and how it's meant to be used.

• Ravenscar only cares about the concurrency of the program. In other words, Ravenscar only touches the following two features of Ada:
  • Tasks
    • fixed set of parallel threads of control that run from program start to program termination
    • the code running in a task is essentially sequential – notably, tasks are not by themselves used for synchronisation and communication
  • Protected objects
    • used for communication (protected procedures for writing to a shared value, protected functions for reading from a shared value)
    • also used for synchronisation (protected entries allow processes to wait until some condition in the protected object is met)