Remove CAS loop in release of ticket_lock.
-
Maintainer
Not sure whether my proof can be simplified. The purpose of the exclusive RA is to ensure that the value of
owner
is not changed in between the read and write inrelease
.@zhangz
-
Contributor
Impressive, the new
release
is much more sensible now :) The old CAS loop is (unfortunately) introduced due to my reasoning that two "bump counter by 1" are somewhat symmetric, as well as the fact that I previously used a bundle value pair pointed by a single location instead of a pair of locations.For further simplification, I imaged a new invariant like this (based on my previous definition):
Definition lock_inv (γ1 γ2: gname) (lo ln: loc) (R : iProp Σ) : iProp Σ := (∃ (o n: nat), ln ↦ #n ★ auth_inv γ1 (tickets_inv n) ★ ((( lo ↦ #o ★ own γ2 (Excl ()) ★ R) ∨ auth_own γ1 (GSet {[ o ]})))%I.
i.e. moving the
lo
's ownership to local control. So when we try torelease
, it is exclusively owned locally which saves the trouble of proving this fact. However, this can mess up the standard lock interface (EDIT: maybe not, we just need to provelocked
to be exclusive).As a side note, I am not sure the motivation behind turning a list of RAs into a product one (However, introducing a pair of ghost names is not very elegant, but it was easier to reason about for me at that time). So I'd like to hear some general comments on whether these two approaches are interchangeable and which one should we prefer in which case.
Thanks
-
Maintainer
The old CAS loop is (unfortunately) introduced due to my reasoning that two "bump counter by 1" are somewhat symmetric, as well as the fact that I previously used a bundle value pair pointed by a single location instead of a pair of locations.
I see.
i.e. moving the lo's ownership to local control. So when we try to release, it is exclusively owned locally which saves the trouble of proving this fact. However, this can mess up the standard lock interface (EDIT: maybe not, we just need to prove locked to be exclusive).
You can do that, but I am not sure whether it makes it easier: you somehow need to make the
locked
predicate be aware of the location. You can either do that by defining names to be pairs of locations and ghost names, or by using some ghost state.As a side note, I am not sure the motivation behind turning a list of RAs into a product one (However, introducing a pair of ghost names is not very elegant, but it was easier to reason about for me at that time). So I'd like to hear some general comments on whether these two approaches are interchangeable and which one should we prefer in which case.
Note that in this case, I had to put the exclusive in the auth, so having two different ghost instances would be a bit awkward.