Skip to content

Commit 19ad5f7

Browse files
FedericoVagaJonathan Corbet
authored andcommitted
doc:lock: remove reference to clever use of read-write lock
Remove the clever example about read-write lock because this type of lock is not recommended anymore (according to the very same document). So there is no reason to teach clever things that people should not do. Signed-off-by: Federico Vaga <[email protected]> Acked-by: Will Deacon <[email protected]> Signed-off-by: Jonathan Corbet <[email protected]>
1 parent d62e805 commit 19ad5f7

File tree

1 file changed

+0
-12
lines changed

1 file changed

+0
-12
lines changed

Documentation/locking/spinlocks.rst

Lines changed: 0 additions & 12 deletions
Original file line numberDiff line numberDiff line change
@@ -139,18 +139,6 @@ on other CPU's, because an interrupt on another CPU doesn't interrupt the
139139
CPU that holds the lock, so the lock-holder can continue and eventually
140140
releases the lock).
141141

142-
Note that you can be clever with read-write locks and interrupts. For
143-
example, if you know that the interrupt only ever gets a read-lock, then
144-
you can use a non-irq version of read locks everywhere - because they
145-
don't block on each other (and thus there is no dead-lock wrt interrupts.
146-
But when you do the write-lock, you have to use the irq-safe version.
147-
148-
For an example of being clever with rw-locks, see the "waitqueue_lock"
149-
handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from
150-
within an interrupt, they only read the queue in order to know whom to
151-
wake up. So read-locks are safe (which is good: they are very common
152-
indeed), while write-locks need to protect themselves against interrupts.
153-
154142
Linus
155143

156144
----

0 commit comments

Comments
 (0)