From owner-freebsd-hackers Mon Aug 20 10:47:12 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id AD65037B410 for ; Mon, 20 Aug 2001 10:47:09 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.4/8.11.2) id f7KHl7l52745; Mon, 20 Aug 2001 10:47:07 -0700 (PDT) (envelope-from dillon) Date: Mon, 20 Aug 2001 10:47:07 -0700 (PDT) From: Matt Dillon Message-Id: <200108201747.f7KHl7l52745@earth.backplane.com> To: Sandeep Joshi Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: long-term kernel locks References: <3B813AF2.BC7C726@research.bell-labs.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :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