Date: Thu, 28 Aug 2025 22:10:05 +0200
Here's a revised proposal for the timed lock algorithms for multiple
lockables.
Changes:
* They now return `int` and the best motivation I could think of
for that was added to the rationale.
* My reason for why they accept zero or more lockables was added
to the rationale.
* "sentence 11" eradicated.
* "instroduced" corrected.
* Typeface for "unlock" corrected in sentence 7.
* [[nodiscard]] discarded.
* Reference implementation changes:
* Updated to return int.
* Now yields to be both smart and polite.
* Removed residue from an earlier version in which there was a loop
around `try_lock_until()` to retry when it fails spuriously. If
try_lock_until() now fails before the timeout, so do the
algorithms. Is this something I should rethink?
I'm guessing these changes don't need to go into the paper before it
gets an official number?
Best regards,
Ted Lyngmo
lockables.
Changes:
* They now return `int` and the best motivation I could think of
for that was added to the rationale.
* My reason for why they accept zero or more lockables was added
to the rationale.
* "sentence 11" eradicated.
* "instroduced" corrected.
* Typeface for "unlock" corrected in sentence 7.
* [[nodiscard]] discarded.
* Reference implementation changes:
* Updated to return int.
* Now yields to be both smart and polite.
* Removed residue from an earlier version in which there was a loop
around `try_lock_until()` to retry when it fails spuriously. If
try_lock_until() now fails before the timeout, so do the
algorithms. Is this something I should rethink?
I'm guessing these changes don't need to go into the paper before it
gets an official number?
Best regards,
Ted Lyngmo
Received on 2025-08-28 20:10:12