Attilio Rao wrote:
2006/12/20, Duane Whitty <[EMAIL PROTECTED]>: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 |Our current locking hierarchy is basically different: III level: lockmgr - sema - sx II level: mutex (sleep/spin/pool) - rwlock - refcount - cv - msleep I level: atomic instructions - memory barriers - sleepqueues/turnstiles (a lower lever means that the upper layer primitives use it as a base. ie: sx locks are build using 1 pool mutex and 2 condition variables). This scheme is far from being perfect due to the presence of 'level 3 primitives' which should never exist. Currently, there is an ongoing efforts to take all the top layer primitives to the level II. On the other side, level I primitives should never be used directly by kernel code, but should only be used as a bottom layer for syncronizing primitives. All you need to care is in the layer 2 and 3 (and possibly should switch to layer 2).
I disagree. There are many uses of atomic operations in the kernel that are not for locks or refcounts. It's a bad idea to use locks if you can achieve the same thing locklessly, with atomic operations. I would personally also add "critical sections" (critical_enter()/critical_exit()) at level I. They can be used instead of locks when you know your data will only be accessed on one CPU, and you only need to protect it from (non-FAST) interrupt handlers. -- Suleiman _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
