Re: Locking fundamentals

Attilio Rao wrote:
2006/12/20, Duane Whitty <duane@xxxxxxxxx>:

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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • Re: Locking fundamentals
    ... >> It seems to me that understanding locking holds the key to ... >> Could someone review my understanding of fbsd locking fundamentals. ... > (a lower lever means that the upper layer primitives use it as a base. ...
    (freebsd-hackers)
  • Re: Layering Question
    ... So, for transport layer class, you would get following names: ... >> - scheduling direction change of primitives, ... if primitives go only upside-down ... A general solution for this problem would require to define abstract layer ...
    (comp.protocols.iso)
  • Re: Layering Question
    ... So, for transport layer class, you would get following names: ... >> - scheduling direction change of primitives, ... if primitives go only upside-down ... A general solution for this problem would require to define abstract layer ...
    (comp.protocols.iso)
  • Re: Layering Question
    ... > - send messages (primitives) to other layers. ... what means 'do nothing more with this state machine, ... i think this owns an explanation on which i am not so clear. ... > but not very performant) - use only one thread per layer ...
    (comp.protocols.iso)
  • Re: Locking fundamentals
    ... It seems to me that understanding locking holds the key to ... (a lower lever means that the upper layer primitives use it as a base. ... Don't drop locks prematurely because acquiring locks is expensive. ... When possible sleep rather than spin. ...
    (freebsd-hackers)