Deadlock is avoided by acquiring locks in a strict order? How often are locks contended in practice? Would the reservation pattern be applicable here? (just wondering)
Locks are granted in the order that signals are received by the locking workflow. Deadlock are prevented by having a timeout for a grant. The reservation pattern could be used in a similar scenario but the implementer would need to decide how to resolve an "overbooked" reservation. Usually this would be by a policy like first-come-first-served, canceling the first reservation, or otherwise prioritizing the reservations. However as mentioned on the "Resolving Racing Requests" slide our users wanted all their requests (i.e reservations) processed in-order and without canceling any of the requests. Given those requirements, in our case a reservation pattern would not grant any benefit.
Deadlock is avoided by acquiring locks in a strict order? How often are locks contended in practice? Would the reservation pattern be applicable here? (just wondering)
Locks are granted in the order that signals are received by the locking workflow. Deadlock are prevented by having a timeout for a grant.
The reservation pattern could be used in a similar scenario but the implementer would need to decide how to resolve an "overbooked" reservation. Usually this would be by a policy like first-come-first-served, canceling the first reservation, or otherwise prioritizing the reservations. However as mentioned on the "Resolving Racing Requests" slide our users wanted all their requests (i.e reservations) processed in-order and without canceling any of the requests. Given those requirements, in our case a reservation pattern would not grant any benefit.