Upgraded temporal/spatial discussion

Upgraded temporal/spatial discussion

[Paul E. McKenney]

Hello, Akira!

In response to your excellent feedback on my attempt to add a lumber
analogy to the temporal properties of locking, I have added the
following commits:

a7a722ddae4c ("SMPdesign: Work in the spacetime partitioning viewpoint")
cb7335f0af79 ("locking: Fold saw-kerf section into existing 7.1.4")
3d14659144cd ("defer/rcuusage: Relate RCU time/space properties to other primitives")

For completeness, the lumber analogy was attempted in these commits:

16131c2c320c ("locking: Add section describing temporal properties of locks")
8da652f6c958 ("locking: Add labels to saw-kerf diagram")
7f5c537e8a46 ("locking: Wordsmithing")

If these updates look good to you, I will cut a release.

							Thanx, Paul

Re: Upgraded temporal/spatial discussion

[Akira Yokosawa]

On Mon, 29 Aug 2022 06:55:33 -0700, Paul E. McKenney wrote:
> Hello, Akira!
> 
> In response to your excellent feedback on my attempt to add a lumber
> analogy to the temporal properties of locking, I have added the
> following commits:
> 
> a7a722ddae4c ("SMPdesign: Work in the spacetime partitioning viewpoint")
> cb7335f0af79 ("locking: Fold saw-kerf section into existing 7.1.4")
> 3d14659144cd ("defer/rcuusage: Relate RCU time/space properties to other primitives")
> 
Thanks for letting me know.

> For completeness, the lumber analogy was attempted in these commits:
> 
> 16131c2c320c ("locking: Add section describing temporal properties of locks")
> 8da652f6c958 ("locking: Add labels to saw-kerf diagram")
> 7f5c537e8a46 ("locking: Wordsmithing")
> 
> If these updates look good to you, I will cut a release.

I'll try to proof-read those commits (hopefully) in a couple of days.

        Thanks, Akira

> 
> 							Thanx, Paul

Re: Upgraded temporal/spatial discussion

[Paul E. McKenney]

On Tue, Aug 30, 2022 at 12:19:43AM +0900, Akira Yokosawa wrote:
> On Mon, 29 Aug 2022 06:55:33 -0700, Paul E. McKenney wrote:
> > Hello, Akira!
> > 
> > In response to your excellent feedback on my attempt to add a lumber
> > analogy to the temporal properties of locking, I have added the
> > following commits:
> > 
> > a7a722ddae4c ("SMPdesign: Work in the spacetime partitioning viewpoint")
> > cb7335f0af79 ("locking: Fold saw-kerf section into existing 7.1.4")
> > 3d14659144cd ("defer/rcuusage: Relate RCU time/space properties to other primitives")
> > 
> Thanks for letting me know.
> 
> > For completeness, the lumber analogy was attempted in these commits:
> > 
> > 16131c2c320c ("locking: Add section describing temporal properties of locks")
> > 8da652f6c958 ("locking: Add labels to saw-kerf diagram")
> > 7f5c537e8a46 ("locking: Wordsmithing")
> > 
> > If these updates look good to you, I will cut a release.
> 
> I'll try to proof-read those commits (hopefully) in a couple of days.

Very good, looking forward to hearing your thoughts!

							Thanx, Paul

[PATCH] defer/rcuusage: Remove redundant back quote

[Akira Yokosawa]

This "`" looks redundant.
Remove it.

Signed-off-by: Akira Yokosawa <akiyks@gmail.com>
---
 defer/rcuusage.tex | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/defer/rcuusage.tex b/defer/rcuusage.tex
index cc4e73d9c014..eba1033bbbc3 100644
--- a/defer/rcuusage.tex
+++ b/defer/rcuusage.tex
@@ -1713,7 +1713,7 @@ RCU's temporal synchronization is provided by the read-side markers,
 for example, \co{rcu_read_lock()} and \co{rcu_read_unlock()}, as well as
 the update-side grace-period primitives, for example, \co{synchronize_rcu()}
 or \co{call_rcu()}.
-The` spatial synchronization is provided by the read-side
+The spatial synchronization is provided by the read-side
 \co{rcu_dereference()} family of primitives, each of which subscribes
 to a version published by \co{rcu_assign_pointer()}.\footnote{
 	Preferably with both \co{rcu_dereference()} and
-- 
2.25.1

Comments in the form of patch

[Akira Yokosawa]

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()}.
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 ... ???
+%%%
 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?
 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

Re: Comments in the form of patch

[Paul E. McKenney]

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

Re: Comments in the form of patch

[Akira Yokosawa]

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