Re: Locking fundamentals

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

Relevant Pages

  • Locking fundamentals
    ... Could someone review my understanding of fbsd locking fundamentals. ... Don't drop locks prematurely because acquiring locks is expensive. ... Atomic operations and memory barriers are the primitives. ...
    (freebsd-hackers)
  • Re: all mutexes -> read-write locks?
    ... locking primitives it has come to be that mutexes and exclusively ... acquired reader-writer locks are almost the same in terms of overhead ... by all means change it to use rwlocks. ... changing it would allow a slow transition to using rw locks. ...
    (freebsd-arch)
  • Re: [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • [RFC] locking.9
    ... Sleep Mutexes ... Shared-Exclusive locks ... deschedules the thread while you are holding a SPIN mutex. ... .Ss Sleep Mutexes ...
    (freebsd-current)
  • Re: locking N mutexes simultaneously
    ... I need to map N mutexes to a sorted array of M mutexes ... acquire locks A B C D E while T2 tries for C E F, ... Lockers of the multimethod simultaneously otherwise I would create ... OBJ queue1 = new; ...
    (comp.programming.threads)