On Wed, Aug 31, 2022 at 11:41:35PM +0900, Akira Yokosawa wrote:
> Hi Paul,
>
> This is a collection of comments in the form of a patch.
> I think you can figure out what I want to say, but if unclear,
> please ask.
>
> Thanks, Akira
> ---
> defer/rcuusage.tex | 2 ++
> locking/locking.tex | 12 ++++++++++++
> 2 files changed, 14 insertions(+)
>
> diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
> index eba1033bbbc3..0cefe84d0e63 100644
> --- a/defer/rcuusage.tex
> +++ b/defer/rcuusage.tex
> @@ -1732,11 +1732,13 @@ locking and by static data-structure layout, respectively.
>
> Hazard pointers can be considerd to combine temporal and spatial
> synchronization in a similar manner.
> +% reference to \cref{lst:defer:Hazard-Pointer Recording and Clearing}?
> The \co{hp_record()} function's acquisition of a reference
> provides both spatial and temporal synchronization, subscribing
> to a version and marking the start of a reference, respectively.
> This function therefore combines the effects of RCU's
> \co{rcu_read_lock()} and \co{rcu_dereference()}.
> +% reference to \cref{lst:defer:Hazard-Pointer Scanning and Freeing}?
> The \co{hp_clear()} function's release of a reference provides
> temporal synchronization marking the end of a reference, and is
> thus similar to RCU's \co{rcu_read_unlock()}.
Good point! I took a stab at this here:
ec15ee942d5c ("defer/rcuusage: Add references to QQ9.65")
> diff --git a/locking/locking.tex b/locking/locking.tex
> index f0b4513995a7..df6458063a89 100644
> --- a/locking/locking.tex
> +++ b/locking/locking.tex
> @@ -1136,6 +1136,13 @@ Of course, locks partition time instead of sawing wood,\footnote{
> are described in \cref{chp:Deferred Processing}.}
> but just like sawing wood, using locks to partitioning wastes some of
> that time due to lock overhead and (worse yet) lock contention.
> +%%% ^^^ I could not parse this sentence for the first time.
> +% ..., [using locks] to [partitioning wastes] [some of that time] ???
> +%
> +% [partitioning wastes] looked like a noun phrase.
> +%
> +% ..., partitioning time with locks wastes some of that time ... ???
> +%%%
This was me changing my mind on how to write the sentence mid-way
through and failing to clean up afterwards. The "to partitioning wastes"
should instead be "to partition time wastes".
69cd68c5aa33 ("locking: Fix time-partitioning typo")
> One important difference is that if someone saws a board into too-small
> pieces, the resuting conversion of most of that board into sawdust will
> be immediately obvious.
> @@ -1178,6 +1185,11 @@ be accessed by the lock holder without interference from other threads.
> The Rust programming language takes lock/data association a step further
> by allowing the developer to make a compiler-visible association between
> a lock and the data that it protects.
> +% A \cite{} or two for the Rust lang?
> +% - https://www.rust-lang.org/
> +% - https://doc.rust-lang.org/book/ch16-00-concurrency.html
> +%
> +% Brief introduction of the Rust lang somewhere in Chapter 2?
Good point! But how about this one?
https://cacm.acm.org/magazines/2021/4/251364-safe-systems-programming-in-rust/fulltext
It talks about safety, but also links it to verification.
729ed701fa72 ("locking: Add Rust citation for lock/data association")
Thoughts?
Thanx, Paul
> When such an association has been made, attempts to access the data
> without the benefit of the corresponding lock will result in a
> compile-time diagnostic.
> --
> 2.25.1
>
>
