Date: Thu, 05 Dec 1996 08:46:59 -0600 From: Chris Csanady <ccsanady@friley216.res.iastate.edu> To: Peter Wemm <peter@spinner.dialix.com> Cc: smp@freebsd.org Subject: Re: make locking more generic? Message-ID: <199612051447.IAA04684@friley216.res.iastate.edu> In-Reply-To: Your message of Thu, 05 Dec 1996 17:25:01 %2B0800. <199612050925.RAA07355@spinner.DIALix.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. Al s > 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. I dont think I have seen this there. Could you post the url? >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. Intention locking is one. There are a few good posts in the mail archives about that. It is also on freebsd-smp page as well.. >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) I wasn't referring to a fine grained implementation right off hand. Just a couple more locks, and it would be quite difficult to get into a deadlock situation with them. Even so, you could still call it giant locking.. :P Chris > >Cheers, >-Peter
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199612051447.IAA04684>