Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 20 Dec 2006 22:07:25 -0800
From:      Suleiman Souhlal <ssouhlal@FreeBSD.org>
To:        Attilio Rao <attilio@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, Duane Whitty <duane@dwlabs.ca>
Subject:   Re: Locking fundamentals
Message-ID:  <458A249D.3030502@FreeBSD.org>
In-Reply-To: <3bbf2fe10612200414j4c1c01ecr7b37e956b70b01fa@mail.gmail.com>
References:  <20061220041843.GA10511@dwpc.dwlabs.ca> <3bbf2fe10612200414j4c1c01ecr7b37e956b70b01fa@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
Attilio Rao wrote:
> 2006/12/20, Duane Whitty <duane@dwlabs.ca>:
> 
>> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?458A249D.3030502>