Thread (41 messages) 41 messages, 11 authors, 2020-03-27

Re: Documentation/locking/locktypes: Further clarifications and wordsmithing

From: Sebastian Siewior <bigeasy@linutronix.de>
Date: 2020-03-25 16:02:50
Also in: linux-acpi, linux-pci, linux-pm, linux-usb, linux-wireless, lkml, netdev, platform-driver-x86

On 2020-03-25 13:27:49 [+0100], Thomas Gleixner wrote:
The documentation of rw_semaphores is wrong as it claims that the non-owner
reader release is not supported by RT. That's just history biased memory
distortion.

Split the 'Owner semantics' section up and add separate sections for
semaphore and rw_semaphore to reflect reality.

Aside of that the following updates are done:

 - Add pseudo code to document the spinlock state preserving mechanism on
   PREEMPT_RT

 - Wordsmith the bitspinlock and lock nesting sections

Co-developed-by: Paul McKenney <paulmck@kernel.org>
Signed-off-by: Paul McKenney <paulmck@kernel.org>
Signed-off-by: Thomas Gleixner <redacted>
Acked-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
quoted hunk ↗ jump to hunk
--- a/Documentation/locking/locktypes.rst
+++ b/Documentation/locking/locktypes.rst
+rw_semaphore
+============
+
+rw_semaphore is a multiple readers and single writer lock mechanism.
+
+On non-PREEMPT_RT kernels the implementation is fair, thus preventing
+writer starvation.
+
+rw_semaphore complies by default with the strict owner semantics, but there
+exist special-purpose interfaces that allow non-owner release for readers.
+These work independent of the kernel configuration.
This reads funny, could be my English. "This works independent …" maybe?

Sebastian
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help