[src/trunk]: src/share/man/man9 upon further reflection, rw_write_held() actu...

[jdolecek <jdolecek%NetBSD.org@localhost>]

details:   https://anonhg.NetBSD.org/src/rev/e1e40f86220e
branches:  trunk
changeset: 446561:e1e40f86220e
user:      jdolecek <jdolecek%NetBSD.org@localhost>
date:      Mon Dec 10 20:12:36 2018 +0000

description:
upon further reflection, rw_write_held() actually seems to be safe
for check that the write lock is not currently held by current lwp - current
lwp can't acquire the rwlock even when preempted

diffstat:

 share/man/man9/rwlock.9 |  6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diffs (20 lines):

diff -r ed3fdee5278d -r e1e40f86220e share/man/man9/rwlock.9
--- a/share/man/man9/rwlock.9   Mon Dec 10 19:29:41 2018 +0000
+++ b/share/man/man9/rwlock.9   Mon Dec 10 20:12:36 2018 +0000
@@ -1,4 +1,4 @@
-.\"    $NetBSD: rwlock.9,v 1.18 2018/12/10 19:21:56 jdolecek Exp $
+.\"    $NetBSD: rwlock.9,v 1.19 2018/12/10 20:12:36 jdolecek Exp $
 .\"
 .\" Copyright (c) 2006, 2007, 2009 The NetBSD Foundation, Inc.
 .\" All rights reserved.
@@ -188,6 +188,10 @@
 they are provided only for diagnostic purposes.
 They are also not atomic, hence they should only be used to assert
 that lock is held.
+The only exception is
+.Fn rw_write_held ,
+which can be also used safely to assert that write lock is NOT currently
+held by current lwp.
 .El
 .Sh PERFORMANCE CONSIDERATIONS
 RW locks are subject to high cache contention on multiprocessor systems,