R/W RNLP Optimizations

Next, we briefly summarize additional optimizations that can be incorporated into theR/W RNLPto improve average-case parallelism, and thus responsiveness in many cases. These optimizations do not affect the worst-case blocking bounds. We describe them independently for ease of exposition, but note that they can be combined in a real implementation. These optimization improve parallelism, and therefore average-case responsiveness, which is often desirable in practice.

4.1.3.1 Requesting Fewer Resources

Requiring write requests to lock an expanded set of resources enabled us to establish Lemma 4.5. This lemma can instead be established by utilizing placeholders, which allow for increased parallelism. Specifically, we require a write requestRw

i to enqueue aplaceholderR p

i in the queues of all non-needed resources that we earlier requiredRw

i to request. In this case, theR/W RNLPfunctions as previously described with the following exceptions. A placeholder is never entitled or satisfied. Instead, each placeholder Ripis removed from the write queue in which it is enqueued whenR

w

i becomes entitled or satisfied. Therefore, until_Rw_i becomes entitled, its associated placeholders prevent later-issued write requests from becoming entitled or satisfied, thereby ensuring that Lemma 4.5 is not violated.

Example 4.1 (continued). Continuing from the example in Figure 4.3, suppose that Rw

1 only needed N1=_{`b}andRw<sub>2</sub> only neededN2={`a, `c}. WhenRw₁ is issued, it would enqueue a placeholder inQwa, but since it is satisfied immediately, the placeholder is removed. When_Rw

2 is issued, it enqueues inQwa and Qw_c, and enqueues a placeholder inQw_b. However,_Rw₂ is not blocked by any conflicting requests, since_Rw₁ only holds the lock on`b, so_Rw₂ can be satisfied immediately at timet=2, thereby improving concurrency.

Using placeholders allows for additional concurrency. However, this parallelism is not reflected in the worst-case blocking bounds under our analysis assumptions.

4.1.3.2 R/W Mixing

Before we show how to relax Assumption 1 to allow jobs to issuemixedrequests, we first extend our notation. We denote the set of resources thatRineeds read (respectively, write) access to asNir(respectively, Nw

a write request. With this notation, a mixed request is a write request_Rw

i withNir6=/0 andNiw6= /0. We also adapt our definition of the read shared relation,_∼. Given two resources`aand`b, we say that`bis read shared with`a, if for some potential request_Ri,`a∈ Ni, and`b∈ Nir.5

The rules of theR/W RNLPsupport mixed requests with only a minor modification. Intuitively, a mixed request is treated almost exactly like an exclusively write request, though there are three key differences. First, an entitled mixed request can be satisfied if all resources for which it requires read access are either unlockedorread locked. Second, when a mixed request is satisfied, resources for which read-only access is needed are read locked, not write locked, which allows read requests to be satisfied concurrently. Third, with respect to writer entitlement (Definition 4.2), blocked write requests treat a resource that is read locked by a mixed request as if it were write locked.

Example 4.1 (continued). Consider the schedule depicted in Figure 4.3, without the placeholder opti- mization described previously. Assume thatRw

2 is actually a mixed request that requires read access to Dr

2={`a, `b}and write access toDw₂ ={`c}. Then whenRr₅is issued at timet=7, because it does not conflict with_Rw

2 (both requests only require read access to`aand`b),Rr₅can be satisfied immediately by Rule R1.

4.1.3.3 R-to-W Upgrading

We call a read request that can be upgraded to a write request, as previously described, anupgradeable request, which we denote as_Ru_i. Intuitively, we treat an upgradeable request as a write request that can optimistically execute read-only code while its needed resources are read-locked to determine if write access is necessary. Since the blocking bounds of a write request assume that it will be blocked by other read requests, the optimistic execution of the read-only section essentially executes for free. Thus, an upgradeable request has the same worst-case blocking bounds as a write request, but may offer additional concurrency if the write segment of the critical section is not required.

To support this behavior in theR/W RNLP, we treatRu

i as two separate logical requests, a read request,6 Rur

i and a write requestR uw

i , which can cancel each other if necessary. (With respect to Property RWP2, an upgradeable request is only one request; logical requests are not counted separately.) When_Ru_i is issued,_Rur i

5_{The read sharing relation may not be symmetric with mixed requests. For example, letN}

i={`a, `b}andNir={`b}. Then`a∼`b,

but`b6∼`a.

is enqueued as a read request and_Ruw

i is enqueued as a write request. IfR uw i is satisfied beforeR ur i , thenR ur i

is canceled and removed from all read queues. If_Rur

i is satisfied first, it executes its critical section, and upon completion or realization that upgrading is not necessary,_Ruw

i is canceled and removed from all write queues in which it is enqueued. IfRu

i must be upgraded, then when the read-only segment of its critical section completes, all resources are unlocked. Later, whenRuw

i is satisfied, the job can execute the write segment of its critical section. Note that the state of any read objects may change betweenRur

i completing andR uw i

being satisfied. Thus,Ruw

i may need to re-read data. If this behavior is unacceptable for a given application, a write request should instead be issued for all resources that could be written.

4.1.3.4 Incremental Locking

Next, we show how theR/W RNLPcan be adapted to allow jobs to incrementally request resources they use within a critical section, as described earlier. We assume that it is knowna priorithe set of all resources that could possibly be requested in this incremental fashion. For example, if resources are ordered, it may be assumed that a request_Rimay issue a nested request while holding`afor any resource`bsuch that`a≺`b. Alternatively, theR/W RNLPcould be implemented such that an outermost request informs the locking protocol which resources it may request in a nested fashion.

To support this functionality, we initially treatRias if it were a request for all of the resources for which it could potentially lock incrementally. From Corollaries 4.1 and 4.2, afterRibecomes entitled, no conflicting request can be satisfied beforeRi. Thus, ifRionly initially requires access to some subsets⊆ Di, it can be granted access as soon as it is entitled and each resource`a∈sis not locked by a conflicting request. Ri remains entitled to all other resources in<sub>D</sub>i\s, thereby preventing other conflicting requests from acquiring those resources. If<sub>R</sub>i later needs some additional resource(s)s0⊆ Di\s, then it waits until each`a∈s0is not locked by a conflicting request. However, because_Riis entitled to all resources inDi, the total duration of acquisition delay across all incremental requests is at most the worst-case acquisition delay previously proven in Theorems 4.1 and 4.2.

Note that entitlement serves a similar purpose as priority ceilings (Sha et al., 1990), since it prevents later-issued requests from acquiring resources that may be incrementally requested.

Example 4.1 (continued). Consider again the example schedule depicted in Figure 4.3. If_Rw₂ were to incrementally lock`aand/or`b, thenRw₂ could begin executing on either or both of these resources starting

at timet=5 when _Rw

1 unlocks`aand`b. IfRw₂ were to incrementally request`c, to which it is entitled beginning at timet=5, then it would block and wait until timet=8 when_Rr₃completes its read critical section. Note that through this incremental locking, some of the critical section of_Rw₂ executed early, serving only to improve concurrency and reduce blocking.