Re: Vnode scope implementation

[David Holland <dholland-tech%netbsd.org@localhost>]

On Thu, Jul 23, 2009 at 06:08:23AM -0400, der Mouse wrote:
 > > Some things that will not (cannot!) change:
 > 
 > >   - there will be some concept of a locked vs. an unlocked vnode;
 > >   - to avoid race conditions, any vnode on which access control
 > >     checks are being made must be locked, and stay locked, from
 > >     before the check is made to after the operation is complete;
 > 
 > I don't expect these will change.  But I think it is probably excessive
 > to say they cannot change, except in a pragmatic/practical sense.  I've
 > seen some very clever algorithms for access to shared data structures
 > without the need for anything like locking, and, while it's not obvious
 > to me how they could be applied to anything like vnodes, I am by no
 > means convinced they can't be.

For present purposes, a pragmatic sense is perfectly sufficient. :-)

Anyhow, ultimately, vnode operations are supposed to be conflict-
serializable, and that means that any other conflicting operations
that might appear in the window between access check and operation
commit need to be either deferred (as with a lock) or failed and
retried later (as might happen with timestamp ordering)... which means
that during this window the vnode is in a state that's equivalent to
locked.

-- 
David A. Holland
dholland%netbsd.org@localhost