The Transactional Conflict Problem

by   Dan Alistarh, et al.

The transactional conflict problem arises in transactional systems whenever two or more concurrent transactions clash on a data item. While the standard solution to such conflicts is to immediately abort one of the transactions, some practical systems consider the alternative of delaying conflict resolution for a short interval, which may allow one of the transactions to commit. The challenge in the transactional conflict problem is to choose the optimal length of this delay interval so as to minimize the overall running time penalty for the conflicting transactions. In this paper, we propose a family of optimal online algorithms for the transactional conflict problem. Specifically, we consider variants of this problem which arise in different implementations of transactional systems, namely "requestor wins" and "requestor aborts" implementations: in the former, the recipient of a coherence request is aborted, whereas in the latter, it is the requestor which has to abort. Both strategies are implemented by real systems. We show that the requestor aborts case can be reduced to a classic instance of the ski rental problem, while the requestor wins case leads to a new version of this classical problem, for which we derive optimal deterministic and randomized algorithms. Moreover, we prove that, under a simplified adversarial model, our algorithms are constant-competitive with the offline optimum in terms of throughput. We validate our algorithmic results empirically through a hardware simulation of hardware transactional memory (HTM), showing that our algorithms can lead to non-trivial performance improvements for classic concurrent data structures.



There are no comments yet.


page 1

page 2

page 3

page 4


Listing Conflicting Triples in Optimal Time

Different sources of information might tell different stories about the ...

Improving High Contention OLTP Performance via Transaction Scheduling

Research in transaction processing has made significant progress in impr...

Distributionally Linearizable Data Structures

Relaxed concurrent data structures have become increasingly popular, due...

Conflict-free Collaborative Set Sharing for Distributed Systems

Collaborative Data Sharing is widely noticed to be essential for distrib...

On the Cost of Concurrency in Hybrid Transactional Memory

State-of-the-art software transactional memory (STM) implementations ach...

Garbage Collection in Concurrent Sets

Garbage Collection in concurrent data structures, especially lock-free o...

The Influence of Malloc Placement on TSX Hardware Transactional Memory

The hardware transactional memory (HTM) implementation in Intel's i7-477...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Several interesting tools and techniques have been developed to address the challenge of making correct decisions about the future while holding limited information, also known as online decision-making [3, 4, 7, 5, 13]. In this context, the ski rental problem [20] is the question of choosing between continuing to pay a recurring cost, and paying a larger one-time cost which eliminates or reduces the recurring cost. The standard setting of the problem is as follows. A person goes skiing for an unknown number of days . On each day he or she can decide whether or not to buy skis for a fixed price . If the person decides not to buy the skis, he or she has to rent them for a fixed cost per day , where is usually equal to 1. The challenge is to find an algorithm that minimizes the expected cost of the ski tour over the number of days .

In this paper, we phrase the problem of resolving conflicts efficiently in hardware transactional systems [18] as an online decision problem. We abstract this task as the following transactional conflict problem. Consider a database or hardware transactional system, which allows concurrent executions of transactions. The following scenario often arises in practice: a transaction accesses a set of data items, and is assigned ownership of a subset of these data items (usually the items in its write set). Assume that is executing concurrently with another transaction , whose dataset intersects with that of . In this case, this conflict of ownership is detected by the transactional system at runtime, and the transactional implementation usually makes one of two choices to resolve the conflict. The first strategy, usually called requestor wins [16, 23], will have the transaction abort the transaction , while takes ownership of the contended data item. The second strategy, called requestor aborts [16], has transaction abort, resolving the conflict in favor of .

To mitigate the high number of aborts caused by such conflicts, a number of hardware proposals, e.g. [23, 15] allow the following strategy: instead of aborting one of the transactions immediately, we allow the transaction a grace period , before aborting it. From the algorithmic perspective, assume our objective is to maximize the likelyhood of a commit, while minimizing the expected value of the delay added to the running time of the two transactions. By introducing a grace period, we increase the running time of the delayed transaction . Yet, since aborts are expensive, if commits during the grace period, we may gain in terms of the sum of runtime costs, since we could significantly decrease the total running time of if we do not abort it. Clearly, given this cost model, the question of optimally setting the grace period is an online decision problem.


Our results are as follows.

  • We formalize the transactional conflict problem for both the requestor wins and the requestor aborts conflict resolution strategies (Section 4).

  • We give optimal deterministic and randomized solutions for both variants (Section 5). Further, we analyze the performance of both schemes in the setting where additional information is provided, in the form of the mean of the underlying distribution of transaction lengths, and when chains of transactions might conflict. We provide closed-form optimal solutions in this case (Section 5.2).

  • We show that, under an adversarial transaction scheduling model, our algorithms are globally constant competitive in terms of the sum of running times of the transactions, i.e. inverse of throughput. (Section 6) Further, we discuss strategies to add probabilistic progress guarantees to our algorithms (Section 7).

  • We validate our strategy on a hardware simulator implementation of HTM [18] and in synthetic tests, showing that it can yield throughput improvements of up to , and that it is competitive with a finely-tuned manual approach (Section 8).

The Transactional Conflict Problem

In more detail, the transactional conflict problem presents the following trade-off. (Please see Figure 1 for an illustration.) Assume transaction is interrupted by a conflicting transaction , in a requestor wins implementation. We have the choice of aborting immediately, or delaying the abort by a grace period , in the hope that the transaction will commit before expires. If the transaction commits after some additional time , then we have added time steps to the running time of ; yet, since commits, we do not incur any additional time penalty for this transaction. If the transaction has not committed within the grace period, then we will abort it. In this case, we wasted time units in terms of the total running time of the transactions: one for which we have delayed , and one for which we have increased the total running time of , without committing it. (Since will have to redo all its computation in case of abort, none of the executed steps is useful.) In addition, we assume that we always incur a (large) cost for having aborted the transaction.

In sum, given the unknown remaining running time of the transaction , the task is to compute the grace period which optimizes the trade-off between the cost we pay in the case where , and the cost which we pay in the case where . This problem clearly appears to be related to the ski rental problem, and it is tempting to think that its solution follows by simple reduction.

However, this is not the case, due to the different structure of the cost function. Perhaps surprisingly, we show that this difference significantly alters the optimal strategy, as well as the competitive ratio. For example, for two transactions and a requestor wins implementation, we prove that the optimal strategy is a uniform random choice in the interval , and its competitive ratio is . By contrast, the optimal strategy for requestor aborts

implementations, which coincides with the classic ski rental problem, is the exponentially decaying probability distribution, with competitive ratio

. This trade-off becomes more complex for conflict chains involving more than two transactions. We also consider this case in this paper.

Extensions and Techniques

We consider and solve two natural extensions of the problem. The first is to consider larger conflict chains, when more than two distinct transactions may be involved in a conflict. The second is the case where the length of each transaction is assumed to come from an arbitrary probability distribution, whose mean is known. For instance, this corresponds to a profiler which records the empirical mean over all successful executions of a transaction, and uses this information when deciding the grace period length.

On the technical side, we give a unified technique for optimally solving parametrized instances of this online decision problem; in particular, we provide closed-form solutions for the general case with arbitrarily many conflicting transactions and mean constraints. Our main analytic tool is a non-trivial instance of the method of Lagrange multipliers tailored to this problem, building on an analysis by Khanafer et al. [8] for the ski rental problem.


Starting from the competitiveness of local decisions, we show that, under a simplified adversarial conflict model for a system of threads executing concurrent transactions, the algorithms we propose are globally competitive with an offline-optimal solution in terms of the sum of running times of transactions (intuitively, the inverse of throughput). Specifically, if the timing of conflicts between transactions is decided by an adversary, then we prove that the running time penalty incurred by all transactions using our scheme is constant-competitive with a perfect-information algorithm, which knows the remaining running time of each transaction at conflict time.

Experimental Results

We validate our results empirically, using both a synthetic testbed, and an implementation of a requestor-wins hardware transactional memory (HTM) system on top of the MIT Graphite processor simulator [22], executing data structure and transactional benchmarks. The synthetic experiments closely match our theoretical results. The HTM experiments suggest that adding delays can improve performance in HTM implementations under contention, and does not adversely impact performance in uncontended ones. Of note, we observe that our algorithms perform well even when compared with a finely-tuned approach, which uses knowledge about the application and implementation to manually fine-tune the delays.


The general problem of contention management in the context of transactional memory has been considered before [14], and several efficient strategies are known, e.g. [14, 17]. The main distinction from our setting is that contention managers (for instance in software TM) are usually assumed to have global knowledge about the set of running transactions, and possibly their abort history. By contrast, in our setting, decisions are entirely local, as well as immediate and unchangeable. In this context, our algorithms implement a distributed, online contention manager. We find it surprising that constant-competitive throughput bounds can be obtained in this restrictive setting.

A second implication of our work concerns requestor wins versus requestor aborts conflict resolution. Most systems only implement one such strategy, but our analytic results show a trade-off between contention and the performance of these two paradigms. In particular, requestor aborts is more efficient under low contention, whereas requestor wins is more efficient when conflicts involve more than two transactions. This suggests that a hybrid strategy, which can alternate between the two, would perform best.

2 Related Work

The ski rental problem was introduced by Karlin, Manasse, Rudolph, and Sleator in [21], where the authors give optimal deterministic -competitive algorithms for the classic version of the ski rental problem. Follow-up work by Karlin et al. [20] showed that randomized algorithms can improve on this competitive ratio to , which is optimal [24]. Several variants of this problem have been studied, e.g. [5, 19, 12, 8], with strong practical applications, e.g. [12, 8]. We refer the reader to the excellent survey by Albers [6] for an overview of the area, and to Section 3.3 for technical background on the problem.

The work that is technically closest to ours is by Khanafer et al. [8]: they define a constrained

version of the ski rental problem, in which constraints such as the mean and variance of the underlying distribution from which the unknown parameter is chosen are added. The authors provide bounds on the improvement in terms of competitive ratio provided by these additional constraints. The basic technical ingredients we employ, notably the method of Lagrange multipliers, are similar to those of this work. However, we consider a significantly more complex instance of the problem, which requires a more involved analysis.

The problem of designing efficient contention management in the context of transactional memory [18] has received significant research attention, especially since such systems are already present in hardware by major vendors [1]. Several applied papers, e.g. [16, 9, 23, 11] discuss the trade-offs involved in implementing transactional protocols in hardware, and the performance pathologies of such systems. Reference [23]

explicitly discusses the possibility of adding delays to hardware transactions, and implements and compares heuristics for tuning these delays. We believe we are the first to abstract the problem of setting the delays while minimizing running time impact, and to solve it optimally. As noted, the contention management problem has been abstracted by 

[14] in the context of software TM (STM), and there is a considerable amount of work on this topic, e.g. [14, 17, 10, 25]. However, to our understanding, all these systems assume a contention manager module with global knowledge about the set of running transactions, which is reasonable in the context of STM; by contrast, we analyze a setting where only local, immediate, and unchangeable decisions are possible, which is the case for HTM.

3 Model and Preliminaries

3.1 Shared-Memory Transactions

We consider an asynchronous shared-memory model in which processors communicate by performing atomic operations to shared memory. We assume that standard read-write atomic operations are available to the processors.

We are interested in a setting where processors execute sequences of basic read-write operations atomically, as transactions. Specifically, a transaction is a set of read and write operations, which are guaranteed to be executed atomically if the transaction commits. Otherwise, if the transaction aborts, then none of the operations is applied to shared memory. Many hardware implementations of transactional memory use some version of the pattern shown in Algorithm 1 below.

1:function transaction(code)
2:     // Use a MESI cache coherence protocol, except each cache line has an additional bit. This additional bit is set if cache line is used by transaction. In this case, cache line is called transactional and it resides in the transactional cache.
3:     // Execution phase
4:     if at any point transactional cache line is evicted, abort transaction.
5:     if transaction is aborted, invalidate all transactional cache lines.
6:     for each access in code do
7:         if read then
8:              Try to acquire the transactional cache line in a shared or exclusive state.
9:              Conflict arises if some transaction has the required cache line in its transactional cache in a modified state.          
10:         if write then
11:              Try to invalidate all existing copies of the required cache line, then change a state of the cache line to modified.
12:              Conflict arises if some transaction has a copy of the line in its tranactional cache.               
13:     // Commit phase
14:     if transaction is not aborted in the execution phase, then commit, by clearing additional bits in all transactional cache lines.
Algorithm 1 Simplified Pseudocode for Hardware Transactional Memory implementation.

Notice that, if several transactions with overlapping read and write sets may execute or attempt to commit at the same time, then they may conflict in the commit phase. In particular, consider the following example, involving transactional objects and :

A transaction performing and a transaction performing from an initial state of can conflict in the commit phase as follows. Imagine holds variable in Exclusive state locally, and is in the process of acquiring variable in Exclusive state, so that it can commit. Then starts executing its Commit phase, and sends a coherence message to , asking for in Exclusive state. At this point, has two choices: it can either relinquish exclusive access of , and abort its transaction (see Figure 0(a)), or delay the request by for some time, hoping that it will commit soon (see Figure 0(b)). In the following, we will look at algorithms for making this choice. Note that we will use both terms algorithm and strategy meaning the same thing from now on.

(a) Requestor wins scenario. Here, has been running for time steps when a conflict with is detected. has the possibility of delaying ’s message response for steps before aborting itself. The “wasted” time added to the execution of both transactions in case aborts is shown in red.
(b) Requestor aborts scenario. Again, has been running for time steps when a conflict with is detected. has the possibility of delaying ’s message response for steps before aborting . The “wasted” time added to the execution of both transactions in case aborts is shown in red.
Figure 1: The transactional conflict problem for the two conflict resolution strategies.

3.2 Conflict and Cost Models

Transaction Conflict Scheduling

As described, we have threads, each of which has a virtually infinite sequence of transactions to execute. Threads proceed to execute these transactions in parallel. At arbitrary times during the execution, an adversary can interrupt a pair of transactions, and put them in conflict: one of them will be the requestor, and the other one is the receiver. The algorithm has the choice of resolving the conflict immediately, by aborting the one of the transactions, or to postpone the abort for a grace period . The cost model is specified for each conflict resolution strategy in Section 4.

Upon aborting a transaction, the thread will restart its execution immediately. Initially, the conflicted transaction will no longer be in conflict with any other transaction, although it may become conflicted if chosen by the adversary. Upon committing a transaction, the thread moves to the next transaction in its input. During its grace period, a receiver transaction may become conflicted as a requestor with another transaction, since it may need to access some new data item.

Additional Assumptions

In the following, we will assume a simplified version of the conflict model, and analyze the global competitiveness of our strategies. In particular, we assume that (a) a transaction that is part of a conflict as a requestor cannot become part of a new conflict as a receiver, (b) a transaction that is currently during its grace period cannot be conflicted again as a receiver by the adversary (but the transaction may be conflicted as a requestor), and (c) that conflicts cannot be cyclic. Assumptions (a) and (b) are in some sense necessary given our strong adversarial model: we wish to ensure that the adversary can only inflict the same set of conflicts on the offline optimal strategy as to the online decision algorithm. We note that assumption (c) is implemented by some real-world HTM implementations, which actively detect conflict cycles, and abort all transactions involved upon such events [2].

Cost Model

Given the above setup, our cost model is defined as follows. Fix an adversarial conflict strategy , and a (possibly randomized) algorithm for resolving conflicts. For each transaction , define be the expected length of the interval between ’s starting time (i.e., the first time it is invoked) and its eventual commit time, assuming conflicts induced by . We analyze strategies for deciding the grace period, which minimize the expected sum of running times of transactions. Formally, we wish to find an algorithm such that, for any adversarial strategy ,

3.3 Background on the Ski Rental Problem

We recall the definition of the ski rental problem [20]: a person goes skiing for an unknown number of days . On each day, he or she can decide whether or not to buy skis for a fixed price . If the person decides to not buy the skis, he or she has to rent them for a fixed cost per day , which we will choose w.l.o.g. to be equal to 1. The challenge is to find an algorithm that minimizes the expected cost of the ski tour over the number of days . The optimal cost with foresight for this problem is clearly , and the optimal online deterministic strategy has cost if . So the deterministic competitive ratio is basically . It is known that one can do better by employing a randomized strategy [20]:


Consider a strategy where, for each day , with probability , we rent skis on day . Then, if we take for days , and otherwise, we pay expected total cost

Using additional knowledge about the adversarial distribution, e.g. the mean , it is known that one can improve the strategy further [8]:


Knowledge of the mean of the adversarial function yields a new randomized strategy for the standard ski rental problem, namely if , then

The competitive ratio improves to . Otherwise, the previous strategy is optimal.

4 The Transactional Conflict

We now formalize our problem, assuming the transactional model in Section 3. As the cost metric is different depending on the contention resolution strategy, we define the problem differently for each case. For simplicity, we will start by defining the problem for the case with two conflicting transactions, and then extend to the case with longer conflict chains.

4.1 Problem Statement for Requestor Wins

Two Conflicting Transactions

Assume that an executing transaction (the receiver) is interrupted by a transaction (the requestor), and that we have the choice between aborting immediately, and postponing ’s abort by steps, in the hope that it commits. Assume that still has to execute for time steps (unknown) to commit, and that aborting immediately incurs a fixed cost .111In practice, the cost will consist of the time for which the transaction has already been running when interrupted, plus a fixed non-trivial cleanup cost. We define the conflict cost as follows: (1) If , then transaction commits at or before , and we only pay the time by which we delayed , which is . In terms of the sum of running times, our delay decision added to the total cost. (2) If , then transaction has not committed at , and we will abort , allowing to continue. We will pay the abort cost , the additional time by which we ran , and the additional time by which was delayed. This sums up to .

The General Case

In general, the conflict chain may be longer, as several transactions may be delayed if we decide to extend ’s execution. For example, a third transaction may already be waiting on to commit at the point where conflicts with . Assume that transactions, including , are conflicting, forming a conflict chain. This means that delaying ’s abort by one step will add time steps to the total running time of all transactions. In this case, the cost metric becomes:

  • If , then commits, and we pay the time by which we delayed all transactions other than , which is .

  • If , then we abort , and pay the abort cost and the additional time by which we ran , as well as the additional time by which other transactions are delayed. This sums up to .

We will first focus on decision algorithms which optimize the expected cost of each conflict. Later, in Section 6, we will show how to use competitive bounds on individual conflict cost to obtain competitive bounds on the throughput. We are trying to identify the probability distribution which minimizes the expected decision cost under arbitrary adversarial choices . Formally, for arbitrary , and fixed and as above,

where we have noticed that for the algorithm will always abort. Notice that the offline optimum is

4.2 Problem Statement for Requestor Aborts

Two Conflicting Transactions

The converse case is when the receiving transaction can abort or delay any requestor transaction . Again, we might choose to delay the conflict resolution by a grace period of steps. Assume that still has to execute for steps to commit, where is unknown. The conflict cost is now as follows:

  • If , then transaction commits at or before , and we only pay the time by which we delayed the incoming transaction , i.e., .

  • If , then transaction has not committed at , and we will abort and continue. In this case, we pay as extra cost , a fixed abort cost, plus the time by which was delayed, i.e. total cost .

Notice that the optimal cost with foresight is . By comparing variables we realize that there exists a direct mapping between the ski rental problem and the requestor aborts version of the transactional conflict problem:

The point where the requesting transaction interrupts transaction marks day 1 of the ski rental problem. Furthermore, we have that , the unknown number of steps until would eventually commit, denotes the day on which the adversary chooses to stop us from skiing. The choice of i.e. the length of the grace period by which delays , is the same as to choose that we buy skis on day . Finally, the fixed extra cost in the transactional conflict problem is the equivalent to the cost of buying the skis. Note that in this case we assume that for the transactional conflict problem if , is not able to commit and thus it aborts. If , will be able to commit on time step . Figure 0(b) illustrates this case. The results in Theorems 3.3 and 3.3 apply to this case.

Generalizing to conflicts of size is also possible:


if the optimal PDF is:

and otherwise the optimal PDF is:


In the requestor aborts case for transactions, we have one receiver transaction and requestor transactions. Therefore in abort case, since we abort transactions, the extra cost becomes . This gives us the following cost function :


Thus our Lagrangian function looks as follows:

We note that, since the adversarial strategy is arbitrary, we will need the following two constraints:


By differentiating the constraint 2 twice w.r.t. and substituting with we get

Solving this first order differential equation gives us:


We can solve for by using the fact that is a PDF


By substituting 4 into our constraint 2 we get

Using 5 we get:


Similarly substituting 4 into constraint 3 we get:


In order for 6 and 7 to be true at the same time we need


Since we know that is a PDF we know that and thus we get

Thus we get the following constraints on :


We immediately realize that the r.h.s. of 9 is positive and strictly increasing, whereas the r.h.s. of 10 is negative. Thus we now know that we must have

Thus our problem becomes:


We already realized that 8

. We further remind ourselves that the solutions to this linear program have to form a convex polytope and that each basic feasible solution is a corner point of that polytope. Therefore we get the following two corner points

This gives us the following ’s

Notice that for we do not take the mean into account and thus are left with the solution for the non-constrained ski rental problem. For we realize that is only valid for small values of . More precisely, . For it simplifies to .

5 Analysis for Requestor Wins

In the following, we will focus on analyzing optimal strategies for the requestor wins strategy. In particular, we will examine the optimal deterministic strategy for the unconstrained case, in which no additional information about the adversarial distribution is known, and optimal randomized strategies for the constrained case

, in which the first moment of the adversarial length distribution is known. (This case also convers the randomized unconstrained case, so we solve them together.)

5.1 The Deterministic Unconstrained Case

Since the algorithm is deterministic, it has to choose a time step at which to abort. Denote by the time step at which the transaction would commit, if allowed to execute. Throughout the rest of this section, unless stated otherwise, the expression we abort means that the receiving transaction aborts.

Observe that the optimal cost is . For simplicity, let us assume that is an integer. There are two cases we need to examine. The first one is , in which we pay cost . The second one is , in which we pay cost . Note that the adversary knows after which time step we decided to abort, and thus will never choose to set the end of transaction after . The following result characterizes the optimal deterministic strategy.


The optimal deterministic strategy always chooses to abort after time steps. This strategy has total cost


Let denote the time step on which we chose to abort. We first notice that we can reduce the case where to , since our cost will not increase after the abort. Thus, delaying the end of transaction can only decrease the competitive ratio. The competitive ratio for looks as follows


For we get

as the competitive ratio. This clearly is a non-decreasing function. Thus the adversary would choose to maximize our cost. Therefore, we have competitive ratio . Because this is at most , the adversary will always prefer . We obtain that our strategy will always yield competitive ratio 13. Analyzing this we get

which is minimized for , yielding ratio:


5.2 Randomized Strategies for Transactional Conflict

In this section, we discuss the transactional conflict problem where we have some knowledge about the distribution of the adversarial function. For simplicity, we will consider the case where , i.e. the conflict involves only two transactions, and address the general case in a later section. Our goal is to prove the following.


For arbitrary adversarial distributions, the following randomized strategy is optimal:
otherwise. This yields competitive ratio for the conflict cost.

Knowledge of the mean of the adversarial function yields the following strategy for the transactional conflict problem. If , then the optimal strategy is

In this case, the competitive ratio improves to If then the unconstrained strategy is optimal.


It is easy to show that for arbitrary adversarial distributions above randomized strategy yields competitive ratio 2. Optimality of this strategy can be proven using the same techniques as in [8]. Note that for , the following strategy is optimal and 2-competitive:
otherwise. Proof is analogous to case.

Let be a time step at which we decide to abort and let be a time step at which we would finish the computation. is chosen with the distribution and is chosen with the distribution . Notice that we will always abort at time step the latest, because otherwise our cost will be greater than if we had aborted at time step 0. If , we pay . Otherwise, we pay . Let be the expected cost for the fixed . We have that

We know that the optimal cost is . This gives us a necessity to introduce non-zero probability for to be chosen from outside the interval , because otherwise the trivial optimal strategy is to never abort. Our goal is to minimize the ratio

Considering that we want to find the best possible solution under the worst case distribution of the adversary our problem looks as follows


We will give a closed-form solution for this as follows. We first construct the Lagrangian function for the maximization problem in 15. Afterwards we will construct its dual to get the necessary constraints. We will then differentiate one of the constraints twice, leaving us with a first order differential equation for . Solving this yields the desired PDF . Finally, we substitute into the constraints to solve for the Lagrangian multipliers.

The Lagrangian function takes as inputs the probability distribution of the adversary and the two Lagrange multipliers and . The two multipliers act as weights for the constraints given by the fact that is a PDF with the mean . Thus, we get the following Lagrangian for the maximization problem:

Therefore, its dual is We note that, since the adversarial strategy is arbitrary and we want to minimize the dual function, we will need constraints and , to ensure that the Lagrangian function does not depend on the choice of . Therefore we get the following minimization problem:


Because the constraint 16 holds for every , we can differentiate it twice with respect to and after we substitute with we get the first order differential equation . Solving this yields our strategy . Using the fact that is a PDF we get that . Since and we further have . Thus our problem becomes:


We immediately realize that for we must have in order to satisfy 18 and 19 simultaneously. We remind ourselves that the solutions to this linear program have to form a convex polytope and that each basic feasible solution is a corner point of that polytope. Therefore we get two corner points with corresponding competitive ratios . Notice that for we do not take the mean into account and thus are left with the solution for the non-constrained ski rental problem. For we realize that is only valid for small values of . More precisely, . Thus, if the optimal PDF is:

Otherwise, the unconstrained strategy is optimal.

5.3 Discussion

Competitive Ratio Comparison

We compare this result with the requestor aborts case (classic ski rental) [8]. Depending on the case distinction, we get:

  • inequality holds: In this case we have a competitive ratio of for requestor wins and for requestor aborts. Clearly, requestor aborts outperforms requestor wins. Additionally, we get that the inequality which has to hold in order for this strategy to be applicable, is less strict for the requestor aborts case.

  • inequality does not hold: If the inequality does not hold we get competitive ratio for the requestor wins strategy and for the requestor aborts strategy. Again, we notice that the competitive ratio of requestor aborts is smaller than the one for requestor wins.

Thus, we can conclude that with respect to the competitive ratio for a single waiting transaction (), the transactional conflict problem should be tackled by the requestor aborts strategy. We note that this may no longer be the case for .

Abort probability

We now examine the probability that a transaction aborts, in the case where . (Otherwise, it is more advantageous to abort the current transaction than to delay the system for steps.) Notice that in this case, the adversary’s best strategy is to set . We obtain the following by direct computation:

  • requestor wins:

  • requestor aborts:

Hence, the requestor aborts optimal strategy is less likely to abort a transaction, under the same conditions.

5.4 Constrained Problem for
Conflict Size

A more involved analysis solves the general case where conflicts are of size .


Consider an instance of requestor-wins transactional conflict where transactions are involved. Given the fixed cost , and the mean of the adversarial distribution , then the optimal PDF is as follows.

If , then :

Otherwise, or if the mean is unknown, the optimal PDF is :


We can follow the same steps as in the case, but with more technical care. Our cost function becomes:

and so the corresponding Lagrangian function is:

We note that, since the adversarial strategy is arbitrary, we will need the following two constraints:


which yields the linear program:


By differentiating 22 twice with respect to and substituting with we get:

Solving this first order differential equation we get

Using the fact that is a PDF we can solve for :

Substituting into the constraint 22 yields:

We know that is a PDF so we have for . This means that . Also, and , and so is an increasing function. Thus, it is enough to check if . This gives us following constraint on :