I'm surprised Reviewable[0] hasn't come up in this discussion. It does a great job of allowing stacked code reviews and even handles rebases nicely; the reviewer sees the diff between commit #1 and commit #1' (prime = after rebase).
CockroachDB[1] has been using it since very early in the project.
Sadly, those benchmarks (at the bottom of the thread) were done with a GCC that already included all the GCC 8.1 bells and whistles - results were unchanged under 8.1.
The downside to this solution is that the concrete option types are exported. I believe it's possible to return unexported types from exported functions, which would solve this, but that golint complains about that pattern.
In addition to being extremely precise, TrueTime is explicit about error in its measurements.
In other words, a call to TrueTime returns a lower and upper bound for the current time, which is important for systems like Spanner or CockroachDB when operations must be linearized.
In effect, Spanner sleeps on each operation for a duration of [latest_upper_bound - current_lower_bound] to ensure that operations are strictly ordered.
Your suggestion might improve typical clock synchronization, but still leaves defining the critical offset threshold to the operator, and importantly leaves little choice for software like CockroachDB other than to crash when it detects that the invariant is violated.
It's not even clear that this is about running. They compared runners to sedentary individuals; this sounds like another "exercise is good" conclusion to me.
Cockroach Labs employee here - the implementation only uses a single context key, so traversing the context linked list is only necessary when the context in hand is a derivative of the annotated context (e.g. obtained via WithTimeout or WithCancel), which is relatively uncommon in practice.
It seems to me that your use-case does not require locking specifically - you just want to make sure no concurrent transactions can clobber your "update A".
As mrtracy explained, such overlapping transactions are linearizable in CockroachDB, so this invariant is preserved without the need for explicit locking.
This appears to hammer GitHub's API pretty aggressively. I attempted to import https://github.com/cockroachdb/cockroach and a few hours later my API limit is exceeded.
One of my old co-workers said it best: "Dear @SpaceX and @NASA security teams: please don't sign your firmware, in case a space gardener ever needs to bust out a hex editor."
Obviously there's no avoiding this, but the author writes in the context of high-level code where OS-provided locking mechanisms are available. Why are we discussing this in a low-level (or embedded, where every ounce of performance matters) context?
CockroachDB[1] has been using it since very early in the project.
[0] https://reviewable.io/
[1] https://github.com/cockroachdb/cockroach