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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
