Date: Thu, 05 Dec 1996 17:25:01 +0800 From: Peter Wemm <peter@spinner.dialix.com> To: smp@freebsd.org Subject: Re: make locking more generic? Message-ID: <199612050925.RAA07355@spinner.DIALix.COM> In-Reply-To: Your message of "Thu, 05 Dec 1996 02:08:20 MST." <199612050908.CAA11365@clem.systemsix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Steve Passe wrote:
> Hi,
>
> >If any of you SMP guys have any words of wisdom, or documentation sources
> >for SMP technology, I would really like to hear from you with pointers. Als
o,
>
> http://www.freebsd.org/~fsmp/SMP/books.html
> http://www.freebsd.org/~fsmp/SMP/threads.html
> --
> Steve Passe | powered by
> smp@csn.net | FreeBSD
There are also several "classes" of locks to consider. The version
that we use to guard the entry/exit points of the kernel allows recursion
and hence has a "nest count" which accounts for it's complexity and it's
impact on the task switch code. By recursion, I mean that a process
can enter the kernel lock, call something which ends up in copyin()
and takes another fault, which re-enters the kernel lock again. it needs
to keep track of how many times each process has entered the kernel so
that it can unwind it correctly.
Then there's a simple boolean lock. It's a simple request/free lock
that does not care which cpu is in it at the time and does not allow
recursion.
ENTRY(boot_lock)
/* This is the Intel reccomended semaphore method */
movb $0xff, %al
2:
xchgb %al, bootlock /* xchg is implicitly locked */
cmpb $0xff, %al
jz 2b
ret
ENTRY(boot_unlock)
movb $0, %al
xchgb %al, bootlock /* xchg is implicitly locked */
ret
/* initial value is 0xff, or "busy" */
.globl bootlock
bootlock: .byte 0xff
Of course, there would be nothing stopping us using this simple lock
primative to protect a counting semaphore that allowed recursion and
didn't have to worry about atomic code.
Then there's the 'lock ; bts ...' (bit test and set) and so on
instructions.
4.4Lite2 has a lock 'manager' as well, that uses a simple lock to protect
the complex locking structures. There is a good description of how this
all fits together in a Lite2 context somewhere on the web. I think this
is on Steve's pages, if not I'll have to check my bookmarks.
There are other lock managers around, I believe Terry has mentioned
one or two tree-based managers as well - these can be used to
control the deadlock risks etc.
Having a single lock is nice and convenient at this stage of the game,
since we do not have to worry so much about kernel deadlocks while we
figure out the fundamental core functionality. (eg: APIC_IO, IPI's,
TLB sync, scheduling, starup/shutdown, idle loops, NCPU > 2 support etc)
Cheers,
-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612050925.RAA07355>