Re: Comments in the form of patch

[Akira Yokosawa <akiyks@gmail.com>]

On Wed, 31 Aug 2022 11:44:07 -0700, Paul E. McKenney wrote:
> 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")
Looks good!

> 
>> 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".
Ah, that explains.  ;-)

> 
> 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
Yes, this looks like a good read.

> 
> It talks about safety, but also links it to verification.
I do need to read through it.

> 
> 729ed701fa72 ("locking: Add Rust citation for lock/data association")
> 
> Thoughts?
All look good to me.

I have a set of last-minute typo fixes.
Will send them soon.

       Thanks, Akira

> 
> 							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
>>
>>