# Relaxed Data Types as Consistency Conditions +
## 7 Application: Hybrid Consistencies  
One application of this work is in hybrid consistency conditions. Hybrid consistency conditions are formed by placing the requirements of different consistency conditions on different operations of an ADT, often by requiring \"strong\" behavior from some operations but only \"weak\" behavior from others [31]. In general, hybrid consistencies allow implementations where some operations, whose behavior is perhaps less critical, run faster, while we can require some operations to behave more strictly, even if this reduces their performance. When comprised of consistency conditions which can be expressed as relaxations, these specifications of different per-operation behaviors are very natural to express in the data type specification. Such per-operation relaxations have been used in several works in the literature (e.g., [PERSON] and [PERSON] [6], [PERSON] et al. [10], [PERSON] et al. [14], [PERSON] and [PERSON] [15]), although not explicitly described as hybrid consistency conditions. As a sequential description, which is potentially more intuitive, moving to data type relaxations could greatly reduce the complexity of programming with hybrid consistencies. We will briefly describe two different data types under hybrid consistency conditions and show how they are naturally expressed as data types with only some operations relaxed. First, consider a read/write register where some \(Write\) instances are strong and must respect each other's real-time order, but some are weak and may be reordered among other weak operations. As a hybrid consistency condition, this could be expressed with a flag on the \(Write\) operation, distinguishing \(Write_{s}\) from \(Write_{w}\), which gives the following consistency condition:  
**Definition 18** (Consistency Condition for Register with Strong and Weak _Writes_). : _A concurrent schedule is legal if there is a permutation \(\Pi\) of all instances in the schedule such that_  
1. _Each Read instance returns the argument of the previous_ \(Write\) _instance in_ \(\Pi\) _or_ \(\bot\) _if there is none._
2. _If_ \(op_{1}\) _and_ \(op_{2}\) _are instances in_ \(\Pi\) _where_ \(op_{1}\) _precedes_ \(op_{2}\) _in the schedule order and either at least one is a_ \(Write_{s}\) _instance or both are Read instances, then_ \(op_{1}\) _precedes_ \(op_{2}\) _in_ \(\Pi\)As in Section 5, we can equivalently express this consistency condition as the following relaxation of a register. This is not technically a relaxation of a simple \(Read/Write\) register, since we need two different \(Write\) operations, but arguably the differentiation between types of \(Write\) instances in the consistency condition is already expressing two different operations. The equivalence holds by construction. **Definition 19** (Register with Strong and Weak \(Write\)s). :
1. \(OPS=\{Read,Write_{s},Write_{w}\}\)
2. \(\mathcal{L}\) is the set of all sequences of instances of operations in \(OPS\) such that each Read instance \(rop\) returns the argument of any \(Write\) instance \(wop\) (\(Write_{s}\) or \(Write_{w}\)) starting with the latest preceding \(Write_{s}\) (or \(\bot\) if there is no preceding \(Write_{s}\)) up to and not including the next \(Write_{s}\), such that no previous Read returned the argument of a \(Write\) instance later than \(wop\). Another example, which does not add new operations to the data type, is a FIFO queue where the \(Enqueue\) and \(Dequeue\) operations are strict, so that removing elements exactly follows insertion order, but the \(Peek\) operation is relaxed to speed up attempts to just read the structure. **Definition 20** (Hybrid Consistency for Queues with Weak \(Peek\)). : _A concurrent schedule is legal if there is a permutation \(\Pi\) of all instances in the schedule which respects the schedule partial order of non-overlapping instances where_  
1. \(\Pi|_{\{Enqueue,Dequeue\}}\) _is legal by the specification of a FIFO queue and_
2.