Políticas de precios: Precios de introducción, operación, mecanismos para

In this dissertation, we consider three types of shared resources that differ with respect to their sharing constraint.Mutual exclusionof accesses is required forserially reusableresources, which may be used by at most one job at any time.Reader-writer exclusion(Courtoiset al., 1971) is sufficient if a resources’s state can be observed without affecting it: onlywrites(i.e., state changes) are exclusive and multiplereadsmay be satisfied simultaneously. Resources of which there arekidentical replicas are subject to ak-exclusionconstraint: each replica is only serially reusable and thus requires mutual exclusion, but up tokrequests may be satisfied at the same time by delegating them to different replicas.

Mutex constraints are most common in practice. However, the need for RW synchronization arises naturally in many situations, too. Two common examples are few-producers/many-consumers

Notation Interpretation Constraint / Definition

`q A shared resource. 1≤q≤nr

Ri,q,v Thevthresource request by anyJifor resource`q. v≥1

Li,q,v The request length ofRi,q,v. Li,q,v ≤Li,q

Ni,q Maximum number of requests for`qissued by anyJi.

Li,q Maximum length of any request for`qissued by anyJi. Ni,q= 0⇒Li,q = 0 NR

i,q Maximum number of read requests for`qissued by anyJi. LR

i,q Maximum length of any read request for`qissued by anyJi. Ni,qR = 0⇒LRi,q = 0 NW

i,q Maximum number of write requests for`qissued by anyJi. LW

i,q Maximum length of any read write for`qissued by anyJi. Ni,qW = 0⇒LWi,q= 0

kq Number of replicas of`q. kq≥1

bi Maximum duration of priority inversion incurred by anyJi. see Section 2.4.2

si Maximum duration of spinning incurred by anyJi. see Section 2.4.4.1

Table 2.8: Summary of notation related to resource sharing.

configuration information). Of the three constraints, we expectk-exclusion constraints to be the least common. However,k-exclusion is required whenever there are multiple identical co-processors. For example, a system might contain multiplegraphics processing units(GPUs) ordigital signal proces- sors(DSPs). Theoretically, one could further consider replicated resources with RW constraints, but we are not aware of any practical applications where such constraints arise and do not consider this combination of constraints.

Notation. We formalize resource sharing among sporadic tasks as follows (and as summarized in Table 2.8). Besides themprocessors, the system containsnrshared resources`1, . . . , `nr. When a jobJirequires a resource`q, whereq∈ {1, . . . , nr}, itissuesarequestfor`q. We letRi,q,vdenote

thevth_{resource request by taskT}

ifor resource`q, wherev≥1. In other words,Ri,q,vcorresponds

to thevth _{time that anyJ}

i requires`q sinceTi was launched. In the case of RW constraints, we

analogously let_RR_i,q,vand_RW_i,q,vdenote thevth_{read and write request for`}

q, respectively.

A request_Ri,q,v issatisfiedas soon as Ji holds`q, andcompleteswhenJi releases`q. The request lengthis the time thatJimust execute before it releases`q; we let_Li,q,vdenote the request

length ofRi,q,v. If a requestRi,q,vcannot be satisfied immediately, thenJiincursacquisition delay

and cannot proceed with its computation while itwaitsforRi,q,vto be satisfied. Jobs wait by either

job release job completion

job deadline job scheduled request issued critical section acquisition delay request satisfied request complete acquisition delay request length request span time T_i

Figure 2.26: Illustration of the phases of a request. A job must wait by either spinning or suspending while it incurs acquisition delay.

starts whenRi,q,vis issued and lasts until it completes,i.e., it includes the request length and any

acquisition delay. The different phases of a resource request are illustrated in Figure 2.26.

Requests may be issued at any time during a job’s execution, and no particular order of requests is assumed. In particular, we do not assume a minimum separation between consecutive requests. We letNi,qdenote the maximum number of times that anyJi requests`q, and letLi,q denote the

maximum length of such a request, whereLi,q= 0ifNi,q = 0. When discussing RW resources, we letNR

i,qandNi,qW denote the number of read and write requests, respectively, with the interpretation

thatNR

i,q+Ni,qW =Ni,q. We letLRi,qandLWi,qdenote bounds on the maximum read and write request

length (analogously toLi,q). In the context of shared resources withk-exclusion constraints, we let

kqdenote the number of replicas of resource`q.

While executing a request, Ji is said to be in acritical section. We assume thatJi must be

scheduled on a processor while using a resource, that is, Ji’s request only progresses towards

completion whenJi is allocated a processor. This is required for shared data objects, but may be

pessimistic for some I/O devices. The latter can be accounted for at the expense of more-verbose notation. We assume that each task’s execution requirementeialready accounts for critical sections ofTi(but not for cycles lost to spinning, if any).

If jobJi issues a requestRi,q,w after a previous requestRi,q,v has been satisfied but before

Ri,q,vis complete, thenRi,q,wis aninner requestthat isnestedwithin theouter requestRi,q,v. An outermostrequest is not nested within any other requests. Unless noted otherwise, we assume that resource requests are not nested within each other,i.e., jobs request at most one resource at any time. Resource nesting is considered in the context of uniprocessor locking protocols in Section 2.4.3 below and briefly in Chapter 5. When discussing nested requests, we assume that the request length

ready, preemptable

suspended scheduled,non-

preemptable resumed suspended preemptions disabled preemptions re-enabled scheduled, preemptable dispatched preempted

Figure 2.27: Job state transition diagram.

of outer requests includes the request length of inner requests. We further require that tasks do not hold resources across job boundaries.

Job states. To accommodate the locking protocols discussed below, we extend our task model as illustrated in Figure 2.27. A pending job can be in one of the following states: areadyjob is available for execution, whereas asuspendedjob cannot be scheduled. A jobresumeswhen its state changes from suspended to ready. A scheduled job is further eitherpreemptableornon-preemptable, and cannot be descheduled while it is non-preemptable. In other words, a job that enters anon-preemptive sectioncannot be preempted or migrated by the scheduler until it exits its critical section. We assume that pending jobs are ready unless suspended by a locking protocol. A ready job may be suspended regardless of whether it is scheduled; however, jobs may not suspend while being non-preemptable.

Effective priority. A second extension concerns the prioritization functionY(Ji, t). As the example

shown in Figure 2.25 illustrates, the “regular” priority of a low-priority job may be insufficient to guarantee progress when it blocks a higher-priority job. To avoid such situations, a locking protocol may have to temporarily raise the priority of a resource-holding job. To reflect this, we callY(Ji, t)

thebase priorityassigned by the scheduling policy, and lety(Ji, t)denote theeffective priorityofJi, which is determined by the locking protocol based on the resource usage ofJiat timet. We assume that the two priorities match,i.e.,y(Ji, t) =Y(Ji, t), ifJiis not using any shared resource at timet. A priority-driven scheduler instantiated formprocessors will schedule themready jobs with the highest effective priorities at any time, subject to non-preemptivity constraints of earlier-scheduled jobs. In contrast to base priorities, effective priorities are not necessarily unique; any ties are resolved such that the number of preemptions is minimized; that is, ify(Ji, t) = y(Jx, t), thenJi andJx

Partitions and clusters. When bounding locking-related delays under partitioned or clustered scheduling, it is often required to consider the subset of jobs assigned to a particular processor or cluster. We adopt the following notation. Under partitioned scheduling, we letτk denote the set

of tasks assigned to processork, and letPi denote the partition to which taskTiis assigned, i.e.,

∀1≤k≤m: τk ⊆τ andTi ∈τPi. Under clustered scheduling, we analogously letτkdenote the set of jobs assigned to thekth_{cluster and letPidenote the cluster to whichTiis assigned. A taskTl}

islocalto taskTiifPl =Pi, andremoteotherwise.