Change comments around locking. While you _can_ grab vnode locks

as LK_SHARED, the VOP_ code (in all our existing file systems)
was implememted assuming exclusive locking. Use of LK_SHARED
is technically a bug and only works right for uni-processor and
big-lock SMP systems. Our current file systems will blow up
(probably quite subtlely) with LK_SHARED and fine-grained SMP
locking.
This commit is contained in:
wrstuden 2004-05-25 17:27:03 +00:00
parent 12c9a81707
commit f09a7d98b6
1 changed files with 7 additions and 3 deletions

View File

@ -1,4 +1,4 @@
.\" $NetBSD: vnode.9,v 1.20 2003/10/24 07:43:35 wiz Exp $
.\" $NetBSD: vnode.9,v 1.21 2004/05/25 17:27:03 wrstuden Exp $
.\"
.\" Copyright (c) 2001 The NetBSD Foundation, Inc.
.\" All rights reserved.
@ -463,8 +463,12 @@ into an atomic group.
Many file systems rely on it to prevent race conditions in updating
file system type specific data structures rather than using their
own private locks.
The vnode lock operates as a multiple-reader (shared-access lock)
or single-writer lock (exclusive access lock).
The vnode lock can operate as a multiple-reader (shared-access lock)
or single-writer lock (exclusive access lock), however many current file
system implementations were written assuming only single-writer
locking.
Multiple-reader locking functions equivalently only in the presence
of big-lock SMP locking or a uni-processor machine.
The lock may be held while sleeping.
While the
.Em v_vnlock