On Wednesday 20 December 2006 05:18, Duane Whitty wrote: > Hello again, > > It seems to me that understanding locking holds the key to > understanding fbsd internals. > > Could someone review my understanding of fbsd locking fundamentals. > (No assertions here, just questions) > > lock_mgr > -------------------- > mutexes|sx_lock > ------------------- ^ > atomic | mem barriers | > > Don't lock if you don't need to. > Lock only what you need to. > Use the simplest lock that gets the job done. > Don't drop locks prematurely because acquiring locks is expensive. > When possible sleep rather than spin. > > ?????? > Memory barriers order operations > Atomic operations complete without being interrupted > > Atomic operations and memory barriers are the primitives. > > Mutexes are implemented by atomic operations and memory barriers. > Mutexes are relatively simple and inexpensive but may not recurse.
This is not true. See MTX_RECURSE. > > Shared/exclusive locks are more versatile than mutexes in that they > may be upgraded or downgraded from or to shared/exclusive and they > may be acquired recursively. More expensive than mutexes. > > lock_mgr locks are used when reference counting is needed sx_locks are used when you sleep inside the locked piece of code. Mutexes does not allow you to sleep. > Would there be any particular sections of kernel code that you believe > might be enlightening with respects to locking? > > I have read the man pages describing each family of locks, John Baldwin's > BSDCon 2002 paper, Jeffrey Hsu's paper, the Arch handbook, and the source. > > I don't understand it all yet and it feels like I am missing some > fundamental point, especially concerning the lock_mgr family. Does > anyone have some pointers they feel like sharing? > > Does anyone have any good references they can point me to that is > relevant to fbsd given all the recent changes as a result of SMP? > Is The Design and Implementation of the FreeBSD Operating System > still current enough? --HPS _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
