Resource Model

In this chapter, we assume a simplified resource model based on that described in Section 2.2. Specifically, we assume a system containingnrshared mutex resourcesL={`1, . . . , `nr}such as shared data objects or I/O devices. Notably, however, we employ ak-exclusion lock to realize the locks that we construct. Unlike many prior algorithms, we make no distinction between local and global resources, as theRNLPcan be applied to both. Furthermore, lock nesting is allowed, in accordance with the following assumptions. 3.1.1 Nesting

The classic means of supporting fine-grained locking is throughlock nesting, in which a resource-holding job issues anothernested request. IfJiholds no resources when it issues a request, then the request is an outermost request. We denoteJi’skthoutermost request as_Ri,kand the corresponding resourceFi,k. Once Jiacquires a resource, it may issue anested requestfor another resource. IfJiacquires a resource at time tvia an outermost request, andt0 is the earliest subsequent time whenJi holds no resources, then(t,t0]is called anoutermost critical section. Note that resource requests do not have to be properly nested, as seen in Figure 3.1 (here,`a is acquired first, but`b is released last). We letwait(Ji,t)denote the resource for whichJiis waiting at timet if any. The maximum number of outermost requestsJiissues is given byNi. The maximum duration of the kth outermost critical section ofJi isLi,k. For notational convenience, the

second subscript in all request-related notation may be omitted when it is inconsequential,e.g.,Ri has a critical-section length ofLi.

Definition 3.1. A pi-blocked (s-blocked, s-aware, or s-oblivious) job Ji makes progress if at least one resource-holding job thatJi is blocked by is scheduled.

As we will discuss later, there are a few ways thatJican be blocked by other requests.

As described in Chapter 2, we measure the blocking behavior of theRNLPusing the maximum duration of pi-blocking. However, when supporting nested resource requests, a job can be pi-blocked while holding a resource, as seen in Figure 3.1. This “inner” pi-blocking must be included in the analysis of the total duration of pi-blocking. Furthermore, existing analysis of locking protocols is conducted in terms of the maximum

Figure 3.1: Illustration of a jobJi’s outermost critical section. At timet₁,Jiacquires resource`a. At timet2, Jiissues a nested resource request for`b, and is blocked during the interval[t2,t3). At timet4,Jireleases`a. Ji’s outermost critical section spans fromt1tot5whenJino longer holds any shared resources.

critical-section length. In our analysis, we instead consider the maximum execution time of a critical section, since the maximum critical-section length can depend on the duration of “inner” pi-blocking caused by the locking protocol. The maximum critical-section length and the maximum critical-section execution time are the same when theRNLPis compared with single-resource locking protocols.

In order to prevent deadlock, we assume a strict (irreflexive) partial order,≺, on the set of resourcesL such that a job holding resource`bcannot issue a nested request for`aif`a≺`b. In addition to preventing deadlock, this ordering can be used in blocking analysis to reduce pi-blocking bounds.

3.1.2 Dynamic Group Locks

An alternative means of supporting fine-grained locking instead of lock nesting is a mechanism called a dynamic group lock(DGL). Lock nesting allows for multiple resources to be held concurrently, but resources must be acquired individually. In contrast, under coarse-grained group locking, tasks acquire a single lock on the entire set of resources in one operation; however, this set may include far more resources than actually needed. Dynamic group locking merges these two means of allowing for jobs to concurrently access multiple resources. DGLs extend the notion of fine-grained locking by allowing a request to specify asetof resources to be locked. In this way, DGLs provide better concurrency than group locks, and the potential for lower overheads than nested locking when the set of resources to lock in a nested fashion is knowna priori. As we will show, DGLs have the same analytical worst-case blocking as nested locking in theRNLPunder the analysis techniques we present herein.

Note that DGLs can be supported in addition to nested locking, that is, tasks can issue nested DGL requests. Also, with theRNLPextended to support DGLs, individual nested requests can still be performed like before. Such nesting is necessary, for example, when the resource-access sequence is determined by executing conditional statements. Such nesting may be preferable to improve response times, as tasks

Token Holders Token Lock Wait Queue

Resource Wait Queues

Resource Holders

Figure 3.2: Architecture of theRNLP.

are likely blocked by fewer requests. However, even if the set of resources that will actually be required is unknown—for example, when the resource-access sequence is determined by executing conditional statements—DGLs can still be employed to request all resources that might possibly be accessed, to reduce locking overheads.

For ease of exposition, we first present the RNLP assuming lock nesting and no DGLs. Later, in Section 3.5, we extend the rules of theRNLPto support DGLs, and show the parallels in their analyses.