Blocking because of concurrency correctness condition

Question

I am confused about a statement in The Art of Multiprocessor Programming:

Theorem 3.6.2: Let inv(m) be an invocation of a total method. If <x inv P> is a pending invocation in a linearizable history H, then there exists a response <x res P> such that H · <x res P> is linearizable.

...

This theorem implies that linearizability by itself never forces a thread with a pending invocation of a total method to block.

(The Art of Multiprocessor Programming, Herlihy & Shavit, 2008 Edition, page 58)

I understand that partial methods might need to block for correctness reasons. For example, it is reasonable to block a dequeue operation until there are elements to remove.

However, I don't see why any correctness condition (e.g. linearizability or quiescent consistency) would force an invocation of a total method to block. Is there such a case, or am I misreading the implication of the theorem?

Additionally, what does blocking mean in the context of a history? Does blocking remove an item from the history?

Answer 1

For your first question

Q: However, I don't see why any correctness condition (e.g. linearizability or quiescent consistency) would force an invocation of a total method to block. Is there such a case, or am I misreading the implication of the theorem?

The short answer is that serializability is inherently a blocking property. Quoted from Section 3.3 of the paper: Herlihy@TOPLAS'90:

A: Serializability is inherently a blocking property: under certain circumstances, a transaction may be unable to complete a pending operation without violating serializability, even if the operation is total. Such a transaction must be rolled back and restarted, implying that additional mechanisms must be provided for that purpose. For example, consider the following history involving two register objects: $x$ and $y$, and two transactions: $A$ and $B$.

x Read( ) A
y Read( ) B
x Ok(O) A
Y Ok(O) B
x Write(l) B
y Write(l) A

Here, A and B respectively read x and y and then attempt to write new values to y and x. It is easy to see that both pending invocations cannot be completed without violating serializability. Although different concurrency control mechanisms would resolve this conflict in different ways, such deadlocks are not an artifact of any particular mechanism; they are inherent to the notion of serializability itself. By contrast, we have seen that linearizability never forces processes executing total operations to wait for one another.

---

For your second question

Q: Additionally, what does blocking mean in the context of a history? Does blocking remove an item from the history?

A: An operation is blocked in a history if its invocation event has no matching response event.

I am not able to answer the question "Additionally, what does blocking mean in the context of a history? Does blocking remove an item from the history?". My opinion is that it may or may not cause effects in the history. It is non-deterministic.