Thread (9 messages) 9 messages, 5 authors, 2021-05-24

Re: [PATCH] docs: lockdep-design: correct the notation for writer

From: Xiongwei Song <hidden>
Date: 2021-05-24 13:18:26
Also in: lkml

On Mon, May 24, 2021 at 6:33 PM Boqun Feng [off-list ref] wrote:
On Mon, May 24, 2021 at 12:24:00PM +0800, Xiongwei Song wrote:
quoted
On Fri, May 21, 2021 at 11:17 PM Waiman Long [off-list ref] wrote:
quoted
On 5/21/21 2:29 AM, Xiongwei Song wrote:
quoted
From: Xiongwei Song <redacted>

The block condition matrix is using 'E' as the writer noation here, so it
would be better to use 'E' as the reminder rather than 'W'.

Signed-off-by: Xiongwei Song <redacted>
---
  Documentation/locking/lockdep-design.rst | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/locking/lockdep-design.rst b/Documentation/locking/lockdep-design.rst
index 9f3cfca..c3b923a 100644
--- a/Documentation/locking/lockdep-design.rst
+++ b/Documentation/locking/lockdep-design.rst
@@ -462,7 +462,7 @@ Block condition matrix, Y means the row blocks the column, and N means otherwise
      | R | Y | Y | N |
      +---+---+---+---+

-     (W: writers, r: non-recursive readers, R: recursive readers)
+     (E: writers, r: non-recursive readers, R: recursive readers)


  acquired recursively. Unlike non-recursive read locks, recursive read locks
I would say it should be the other way around. Both W and E refer to the
same type of lockers. W emphasizes writer aspect of it and E for
exclusive. I think we should change the block condition matrix to use W
instead of E.
The doc uses 'E'  to describe dependency egdes too. Should we change them
to 'W'? Personally,  both 'W' and 'E' are fine.
I also think Waiman's suggestion is solid, there are two ways to
classify locks:

1.      W (Writers), R (Recursive Readers), r (Non-recursive Readers)

2.      E (Exclusive locks), S (Shared locks), R (Recursive Readers),
        N (Non-recursive locks)

And the relations between them are as follow:

        E = W
        R = R
        N = W \/ r
        S = R \/ r

, where "\/" is the set union.

The story is that I used the way #1 at first, and later on realized way
#2 is better for BFS implementation, also for reasoning, so here came
this leftover..
Thanks for the explanation.
If you are interested, go ahead sending a patch fixing this, otherwise,
I will fix this.
Ok.  Let me fix.

Thanks,
Xiongwei
Regards,
Boqun
quoted
Thanks,
Xiongwei
quoted
Cheers,
Longman
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help