Date: Mon, 20 Aug 2001 15:47:32 -0400 From: Sandeep Joshi <sandeepj@research.bell-labs.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: freebsd-hackers@freebsd.org Subject: Re: long-term kernel locks Message-ID: <3B816954.9CF1134E@research.bell-labs.com> References: <3B813AF2.BC7C726@research.bell-labs.com> <200108201747.f7KHl7l52745@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matt Ok I see..the interlock is a lock on a collection (e.g on vfs mount list) and it can be released once the simple lock within the to-be-locked object has been acquired. These are really spin locks, now that I saw simplelock.s One more clarification if you will.. :-) What is the purpose of the "splhigh" in acquire() ? Is it this that prevents an involuntary context switch in a UP system , while the lock variables are being modified by acquire() ? -Sandeep Matt Dillon wrote: > > :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?3B816954.9CF1134E>