an object by possessing its associated lock. By using the Priority Ceiling Pro- tocol (PCP), GNAT-BB efficiently emulates locks by raising the accessing task’s priority to the priority ceiling of the protected object, as shown in Figure 14. A protected action begins when a task gains the lock and completes once the
lock is released (ARM 9.5.1).
With entries, the complexity of the protected object model increases. An entry provide the same read-write exclusive access to a protected object as a protected procedure, but with an associated barrier. The barrier opens and closes based on the evaluation of the barrier guard. Normally the guard associates with the protected object’s state, necessitating a task to gain the lock of the protected object before evaluating the barrier. An open barrier allows the task to complete the entry call while a closed barrier places the task’s entry call on an internal entry queue and sees the task release the protected object’s lock.
Entry barriers re-evaluate when protected procedures and entries calls com- plete but before the protected action ends. If barriers with queued calls open at the end of the protected action, the protected action services the queues until all open entry queues are empty.
Ada’s protected object rules do not define who services queued entry calls. An expected servicing model would have tasks service their own calls, under the reasonable assumption a task will always execute its own code, as shown on the left of Figure 15. The alternative is a proxy model where another task
Protected Objects
Figure 14
Protected actions for a protected subprogram call. Protection can be implemented using locks or raising the calling tasks priority using PCP.
acquire lock release lock protected action
normal task execution
10 5 5 TASK PRIORITY TASK PRIORITY TIME TIME Locks for a protected object
can be implemented using priority elevation.
On systems using the priority ceiling protocol.
87 REVIEW OF GNAT FOR BARE BOARDS FOR REAL-TIME SYSTEMS
services the entry call on behalf of the caller. The self-service model provides the benefits of:
▶ being more intuitive;
▶ the ability to treat the entry call as a procedure call and not having to transfer entry parameters between tasks;
▶ better utilization on multiprocessor systems, as the leaving task can immediately continue running on another processor;
▶ ensuring a task only executes its own code; and
▶ reported task execution time correlating with the code executed. Despite these advantages, GNAT (and consequently GNAT-BB) use the proxy-ser- vice model (Giering, Mueller & Baker, 1993). Here, the task which initiated the protected action services entry calls on open entry barriers until all open entry queues are empty. GNAT uses the proxy-service model as self-service requires the task leaving the protected object to pass the lock it holds to the task whose entry call needs servicing. However, the locks offered by the platforms GNAT supports do not provide such a lock passing mechanism: the lock can only be released, allowing any waiting task to acquire the lock. While workarounds exist, the authors of GNARL found them inefficient compared to the proxy-ser- vice model (Giering et al., 1993). Furthermore, the proxy-model suits single processor systems by having entry calls serviced in the same context, removing the context switches required by the self-service model (Figure 15 right). The proxy-service model also simplifies GNAT’s implementation of asynchro-
nous transfer of control (ATC) and timed entry calls, features which bifurcate the execution path of a task (Giering & Baker, 1994). Under the proxy-model, another task will automatically service the queued entry call, allowing the call- ing task to execute the abortable part of the ATC without creating a new thread. Self-Service Model (Single Processor)
Self-Service Model (Multi-Processor)
Proxy-Service Model (Single Processor)
Proxy-Service Model (Multi-Processor)
Processor 1 Processor 1
Processor 1 Processor 1
Processor 1 Processor 2 Processor 1 Processor 1
T2 entry call T2 entry call
T1 protected call T1 protected call
Processor 2 Processor 2 protected action T1 executing protected action T2 executing T2 task execution T1 task execution barrier evaluation TASK PRIORITY TASK PRIORITY TASK PRIORITY TASK PRIORITY TIME TIME TIME TIME 9 9 9 9 6 6 6 6 3 3 3 3
Proxy-service model can be more effi cient than the self-service model with the removal of context switches within the protected action.
However, with multiple processors, the proxy-service model holds the fi rst task until the completion of the protected action.
Figure 15
Serving an entry call at the end of a protected action via the self-service and proxy-service methods. Barrier evaluated in existing task context. No other tasks eligible to run. Multiproces- sor results holds when T1 and T2 processor assignments differ.
While the proxy-service model suits GNAT’s needs, the model negatively affects real-time system development. Protected operations are no longer bounded by the length of the protected operation itself: bounds now have to account for the time spent servicing queued entry calls (Figure 16). Thus, a task’s tim- ing analysis requires the entry call timings for each protected object the task accesses and the bound on the number of queue entry calls — unbounded in the general case. Ultimately, schedulability analysis becomes complex. As a result, the worst-case execution time (WCET) for tasks calling protected
objects with entries becomes unnecessarily pessimistic: every protected object access now includes the time spent servicing the worst-case set of queued entry calls. Pessimistic WCET reduces processor utilization and possibly increases costs if the system requires more processing resources to meet system timing requirements. The proxy-model also effects utilization and timing requirements on multiprocessors since it precludes the leaving task from executing outside of the protect object on another processor while the protected action continues (see the multiprocessor examples in Figure 15).
Using the Ravenscar Profile enables GNAT-BB to curb some WCET and sched- ulability analysis complexity under the proxy-service model. Since the profile restricts each protected object to one entry and one queued entry call, a task will only need to service at most one entry call each protected action. ORK supports monitoring task and interrupt execution time, exposing the
functionality via the Ada.Execution_Time package (Zamorano, Alonso, Pulido & la Puente, 2004). However, the reported execution time includes not only the time a task spends executing, but also the time spent by the kernel while using the task’s context. This time includes ORK moving woken tasks to the ready queue (for example Figure 13 on page 86) and while ORK waits for a protected object’s processor lock on multiprocessor systems.
Additionally, the proxy-service model for protected objects complicates track- ing a task’s execution time. Since ORK tracks the execution of a running task, a task’s execution time will include the time spent executing its own code and the time spent servicing entries for other tasks (Figure 16). The reverse also occurs: the calling task does not get credited for the entry call service time if another task services the call.
Together, these issues mean GNAT-BB may report an execution time larger than the calculated execution time bound for the task unless included as part of the analysis. Difficulties exist though in incorporating these extra time sources: the time spent in the kernel requires prior knowledge of how many tasks will