On Thu, Apr 14, 2022 at 05:42:25PM +0000, Hao Lee wrote:
> Hi,
>
> At the beginning of C.3.3 we have supposed the cache line containing "a"
> resides _only_ in _CPU1’s_ cache. I think this is why _CPU0_ has to send
> a "_read_ invalidate message" to _retrieve_ the cache line and invalid
> CPU1's cache line.
>
> However, the answer says the reason is the cache line in question
> contains more than just the variable a. I can't understand the logical
> relationship between this answer and the question. Am I missing
> something here? Thanks.
I added the commit shown below. Does that help?
Thanx, Paul
------------------------------------------------------------------------
commit 36fe14d5ebe406e331a5d89533fe3187d2019898
Author: Paul E. McKenney <paulmck@xxxxxxxxxx>
Date: Sun Apr 17 10:41:33 2022 -0700
appendix/whymb: Clarify QQ C.8
More clearly note the presence of data other than the variable a.
Reported-by: Hao Lee <haolee.swjtu@xxxxxxxxx>
Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxx>
diff --git a/appendix/whymb/whymemorybarriers.tex b/appendix/whymb/whymemorybarriers.tex
index 8f607e35..43f1307b 100644
--- a/appendix/whymb/whymemorybarriers.tex
+++ b/appendix/whymb/whymemorybarriers.tex
@@ -821,9 +821,14 @@ Then the sequence of operations might be as follows:
In \cref{seq:app:whymb:Store Buffers and Memory Barriers} above,
why does CPU~0 need to issue a ``read invalidate''
rather than a simple ``invalidate''?
+ After all, \co{foo()} will overwrite \co{a} in any case, so why
+ should it care about the old value of \co{a}?
}\QuickQuizAnswer{
- Because the cache line in question contains more than just the
+ Because the cache line in question contains more data than just the
variable \co{a}.
+ Issuing ``invalidate'' instead of the needed ``read invalidate''
+ would cause that other data to be lost, which would constitute
+ a serious bug in the hardware.
}\QuickQuizEnd
The hardware designers cannot help directly here, since the CPUs have
