The introduction of LATMs presents a new problem to be addressed by contention man- agement (CM). In particular, CMs will likely be required to manage the forward progress of both locks and transactions alike. While an existing body of research has already been dedicated to the exploration of contention management (CM) for TM [35, 36, 79, 83], these efforts have been restricted to the investigation of transactional forward progress.
5.6.1 Unified Contention Management
Unified contention management (or UCM), as we call it, is a contention management system that controls the forward progress of both optimistic and pessimistic critical sections. Existing CMs, which control the forward progress of transactions, were originally built to manage critical sections that support failure atomicity. Unfortunately, locks are not failure atomic (see Section 5.4.2). Because of this, contention managers must manage the forward progress for locks in a different manner than the forward progress of transactions. In particular, the only point in a pessimistic critical section where a contention manager can manage a lock is just before its critical section begins as demonstrated in Figure 5.11. Due to this, existing CM policies cannot arbitrate lock- based forward progress in the same manner as they arbitrate transaction-based forward progress.
transaction
time
lock
Range of time for contention management
Range of time for contention management (one point: just before lock acquisition)
Figure 5.11: Differences in Transaction- and Lock-Based Contention Management.
lowed to make forward progress before any portion of the critical section is executed. This is a conceptual departure from CMs that only handle the forward progress guarantees of transactions. Such transaction-based CMs typically decide which transactions will be allowed to make forward progress after the transactions have executed in part or in full. The range of potential contention management for transactions is shown in Figure 5.11.
5.6.2 Our LATM UCM
In building our LATM, we began to explore the space of unified contention management by constructing a basic UCM. Because we have just begun to explore the UCM space, we currently only implement a single UCM policy for locks and transactions, which we call UnifiedFair, but we plan to significantly extend this work in the future.
Lock-based Forward Progress. UnifiedFair stalls the forward progress of locks for some
constant time C if conflicting transactions are active. Once C has expired, UnifiedFair aborts all active transactions that are revocable and of equal or lesser priority than the lock-based critical sec- tion. In the event an irrevocable or isolated transaction is in-flight, UnifiedFair adds the lock-based critical section to its management queue which forces future irrevocable and isolated transactions to execute after the waiting lock-based critical section. This behavior prevents the lock’s critical section from starving.
Transaction-based Forward Progress. Managing transaction-based forward progress in a UCM requires additional measures that are not present in CMs that only manage the forward progress of transactions. One problem of particular importance is that UCMs can indefinitely stall transactions as lock-based critical sections continue to take precedence over transactions, ultimately causing some transactions to starve. To prevent this and other malign behaviors, UnifiedFair has the following specification.
First, when a lock-based critical section is executing, all conflicting transactions are stalled until the already active lock-based critical section has completed. UnifiedFair then allows the stalled transactions to begin their execution and prevents new lock-based critical sections from interference with their execution. Unfortunately, this alone is insufficient. Because transactions can abort one another, transactions that were previously stalled by a lock-based critical section can be aborted by a committing transaction that has higher priority. This cycle could repeat indefinitely unless some mechanism is put in place to prevent it.
UnifiedFair prevents the above cycle from repeating indefinitely by raising a transaction’s priority by the number of lock-based critical sections that have stalled it and the number of trans- actions that have aborted it. Eventually, using this dynamic priority assignment, similar to the one described in Chapter 4, no transaction will be indefinitely stalled.
5.6.3 Open Questions of UCM
While we believe our initial work on UnifiedFair is an important first step in UCM, there are many important problems that we have not yet addressed. Some, but not all, of those open problems are listed below:
• Transactional operations are inherently more costly than those operations inside of a lock- based critical section. This is because transactions must be failure atomic and therefore must perform some logging to unwind operations of aborted transactions or redo operations of a committed transaction. Operations inside a lock-based critical section do not perform
such operations so they are inherently cheaper to perform. Due to this, can we construct an operational weight formula that calculates the weight of lock-based operations and transactional operations, while taking into account how many times a transaction has been aborted and how long a lock-based critical section has been stalled?
• Once a lock-based critical section begins execution it generally must execute to completion. As such, is there a metric, other than the previously discussed stall period, in which the UCM can effectively arbitrate forward progress of lock-based critical sections?
• Is using the period of time it takes for a lock-based critical section to execute a reasonable metric for determining future execution behavior for the same lock-based critical section? If so, how should this value be used compared to transaction executions? If not, is it practical to require additional annotations on locking APIs regarding which methods they are being acquired and released from to help more accurately estimate future locking behavior (e.g., lock(lockA, methodB))?
• In our UCM, a waiting lock with the same priority of an in-flight transaction can abort the transaction, yet a waiting transaction cannot abort an in-flight lock even if the lock is of lesser priority. What mechanisms should be put in place to prevent transactions from becoming second-class citizens to locks?