Skip to content

Commit

Permalink
doc:lock: remove reference to clever use of read-write lock
Browse files Browse the repository at this point in the history
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]>
  • Loading branch information
FedericoVaga authored and Jonathan Corbet committed Sep 14, 2019
1 parent d62e805 commit 19ad5f7
Showing 1 changed file with 0 additions and 12 deletions.
12 changes: 0 additions & 12 deletions Documentation/locking/spinlocks.rst
Original file line number Diff line number Diff line change
Expand Up @@ -139,18 +139,6 @@ on other CPU's, because an interrupt on another CPU doesn't interrupt the
CPU that holds the lock, so the lock-holder can continue and eventually
releases the lock).

Note that you can be clever with read-write locks and interrupts. For
example, if you know that the interrupt only ever gets a read-lock, then
you can use a non-irq version of read locks everywhere - because they
don't block on each other (and thus there is no dead-lock wrt interrupts.
But when you do the write-lock, you have to use the irq-safe version.

For an example of being clever with rw-locks, see the "waitqueue_lock"
handling in kernel/sched/core.c - nothing ever _changes_ a wait-queue from
within an interrupt, they only read the queue in order to know whom to
wake up. So read-locks are safe (which is good: they are very common
indeed), while write-locks need to protect themselves against interrupts.

Linus

----
Expand Down

0 comments on commit 19ad5f7

Please sign in to comment.