Date: Mon, 20 Aug 2001 10:47:07 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Sandeep Joshi <sandeepj@research.bell-labs.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: long-term kernel locks Message-ID: <200108201747.f7KHl7l52745@earth.backplane.com> References: <3B813AF2.BC7C726@research.bell-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:Hi there,
:
:I need some mechanism to hold long-term locks (across
:context switches) while using kernel threads (kthread_*)
:and lockmgr() looked like the right thing to use.
:
:I am running FreeBSD 4.1 on a uniprocessor (..the questions
:are similar with 4.3)
:
:Looking at kern_lock.c, I see that lockmgr() uses simple
:locks. On a UP system, simple locks are turned off.
:I dont see any way to prevent a context switch while the
:kernel thread is in the lockmgr code - after going
:thru a simple_lock() call. Is this correct ?
:
:So my questions are :
:1) Is lockmgr safe ?
:2) Are there other sync primitives that can be used
: between two kernel entities (i can move to 4.3)
:3) What is the use of simplelock_recurse in
: kern_lock.c ?
:
:TIA,
:-Sandeep
Ah, the wonderful world of lockmgr(). This function actually
implements long term locks. It uses simplelock() internally
to force consistent state for short periods of time - which really
only applies to SMP environments, which is why simplelock() is a
NOP on UP systems.
For an example of long-term in-kernel locks, take a look at
kern/vfs_subr.c. Search for 'lockinit' and 'lockmgr' calls.
lockmgr() is in fact what you want to use.
You should be able to safely ignore the interlock stuff for your
purposes. interlock is passed in order to allow lockmgr() to
release the simplelock that the caller was holding in order for
lockmgr() to be able to sleep, and then gain it back later.
i.e. the caller may simplelock() something it is managing and then
want to call lockmgr() to get a real lock 'atomically'. The atomicy
is achieved by the caller maintaining its hold on the simplelock()
through the call to lockmgr(). But simplelock()'s cannot survive
context switches so the caller must pass the simplelock to lockmgr()
so lockmgr() can release it temporarily when it decides it needs to
block. Weird, but it works.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108201747.f7KHl7l52745>