SERVIR AL REY EN LOS REALES SITIOS

In Section 6.2, we show that prior analysis approaches are inherently pes-simistic due to execution time inflation. Our analysis, that we presented in this chapter, eliminates this source of pessimism. Yet, our analysis cannot be generally guaranteed to yield tight (i.e., exact) blocking bounds (except for special cases, such as the case we describe in Section 7.3.3). This was a deliberate choice: our goal was not to ensure tight blocking bounds, but to devise a simple analysis approach that supports lock types for which no prior analysis was available and improves upon prior techniques. Tightness can potentially be achieved at the expense of an increased complexity of the analysis approach. However, the development of a tight blocking analysis is beyond the scope of this work.

Next, we consider the computational cost required by our analysis.

6.6.2 Computational Complexity

In contrast to prior analyses (e.g., the classic analysis of the MSRP summa-rized in Section 2.5.1), our analysis approach makes use of “heavy machinery”, namely MILP. As we argue in Section 6.5, in the case of non-preemptable spin locks, integer variables can be eliminated by transforming the MILP into a set of (non-integer) LPs. As we will show next, when using this transformation, our blocking analysis of F|N locks can be carried out within polynomial time.

Recall from Section 6.3 that our blocking analysis is used in conjunction with a response-time analysis (Equation (1) in Section 6.3), similar to, for instance, the classic MSRP analysis (where the response time analysis in Equation (2.2) uses inflated execution times). Response-time analysis alone, however, is already a (weakly) NP -hard problem [65], even without blocking analysis. Therefore, we only consider the computational complexity of the blocking analysis itself (i.e., generating and solving one MILP as described in this chapter) in the following. We first consider F|N locks before discussing the analysis complexity of the other lock types supported by our analysis approach.

We begin by observing that our analysis uses only a polynomial number of LPs for a single task.

Lemma 14. The elimination of integer variables in the generated MILP as described in Section 6.5 results in a polynomial number of non-integer LPs with respect to the size of the problem description (i.e., the list of tasks and their critical sections).

Proof. Recall from Section 2.1.4 that each resource in Q is accessed at least once, and hence, at least one critical section for each resource must be listed in the problem description, which lower-bounds its size at Ω(n + nr) bits.

The claim follows since one LP is generated for each resource. 

Each of the generated LPs is of polynomial size.

Lemma 15. Each generated LP used for the analysis of F|N locks is of polynomial size with respect to the size of the problem description.

Proof. By construction, per task and resource, two (aggregate) blocking variables (for spin delay and arrival blocking) are used, resulting in O(n · nr) blocking variables in total. Further, by construction, for each type of constraint, O(n · nr) individual constraints (one for each resource and task) are generated.

Since the size of the problem description is lower-bounded by Ω(n + n_r) and the number of constraints and variables are each polynomial with respect to the size of the problem description, it follows that each LP is of polynomial size with respect to the size of the problem description. 

Generating each constraint in the LP only takes polynomial time.

Lemma 16. Any single constraint for the analysis of F|N locks can be generated within polynomial time with respect to the size of the problem description.

Proof. Recall from Section 2.1 that the task set and the set of resources are represented as sets (rather than, for instance, just the number thereof).

Iterating over the set of tasks and resources, as we do for the construction of the constraints, takes linearly many steps with respect to the size of the respective sets. Further, the set operations (e.g., τ (P_k)) and functions (e.g., ncs(Ti, q)) summarized in Table 6.1 used for constructing the constraints for F|N locks can all be carried out within strictly polynomial time with respect to the size of the problem description. The claim follows. 

Since each LP is of polynomial size, and generating each constraint takes only polynomial time, each LP can be generated within polynomial time as well.

Finally, we can conclude that the analysis of F|N locks can be carried out within polynomial time.

Lemma 17. The blocking analysis of F|N for a single task can be carried out within polynomial time with respect to the size of the problem description.

Proof. Follows from the preceding lemmas. For the analysis of a single task, a polynomial number of LPs are generated within polynomial time, where each LP is of polynomial size. Further, each LP can be solved within polynomial

time [78, 88]. The claim follows. 

The analysis of F|P locks makes use of additional n_r integer variables (C_q).

When these variables are relaxed (at the cost of potentially increased pes-simism), the previous argument applies and the analysis of F|P can be carried out within polynomial time as well.

Although the size of the LPs for the analysis of the remaining lock types (i.e., U|*, P|*, and PF|* locks) is polynomial as well, the cost of generating the LPs differs from the cost of generating the LPs for F|* locks in one crucial aspect: for each lock type with priority-ordering (or no guaranteed ordering) we use per-request wait-time bounds to obtain the constraints for the LP (e.g., Constraint 10 for P|N locks). We compute these wait-time bounds by solving a recurrence (e.g., Equation (3) for P|N locks) via fixed-point iteration, similar to response-time analysis for fixed-priority scheduling. In the case of response-time analysis, it has been shown that the response-time cannot be computed within polynomial time (unless P = NP ) [65], and hence, it is unlikely that wait-time bounds can be computed within polynomial

time. However, since we have a stop criterion in the fixed-point iteration, the time for computing the wait-time bounds is pseudo-polynomially bounded in the period of each task: the fixed-point iteration is aborted if no fixed point smaller than or equal to the period of the task is found. Hence, in each iteration, the preliminary value of the wait-time bound is either increased by at least 1 (recall from Section 2.1.1 that we assume discrete time), or a fixed point is found. Hence, the number of steps taken in the fixed-point iteration process is pseudo-polynomially bounded by the task’s period. Except for the computation of the wait-time bounds, the generation and solving of the LPs for the analysis of U|*, P|*, and PF|* locks is polynomial with respect to the input size, similar to the LPs for F|* locks. To summarize, overall the analysis for U|*, P|*, and PF|* locks takes pseudo-polynomial time. If the constraints using wait-time bounds are omitted (at the cost of potentially increased pessimism), the analysis can be carried out within polynomial time as well.

Next, we present the results of a large-scale experimental evaluation, where we investigated the impact of the different spin locks types and analyses in a broad range of different scenarios.

6.7 Evaluation

We conducted a large-scale experimental evaluation comparing all considered spin lock types and analyses (where available) to answer the following key questions:

Q1: Does our blocking analysis approach yield less pessimistic blocking bounds than prior analysis techniques, and hence, higher task set schedulability?

Q2: Can we identify a spin lock type that is a reasonable default choice?

Q3: Are the dominance relations between spin lock types reflected in schedu-lability results?

To answer these questions, we implemented our analysis approach as described above, and we performed a large-scale experimental evaluation in a variety of different settings.