Date: Thu, 5 Dec 1996 10:55:33 -0800 From: Thomas Pfenning <thomaspf@microsoft.com> To: "'Chris Csanady'" <ccsanady@friley216.res.iastate.edu>, "'Peter Wemm'" <peter@spinner.dialix.com> Cc: "'smp@freebsd.org'" <smp@freebsd.org> Subject: RE: make locking more generic? Message-ID: <c=US%a=_%p=msft%l=RED-81-MSG-961205185533Z-4388@INET-02-IMC.microsoft.com>
next in thread | raw e-mail | index | archive | help
Doesn't the lock version in this mail actual trash the cached value for bootlock on every spin? What about using MCS queueing locks to solve both the cache trashing and the reentrance at the same time. Cheers Thomas >-----Original Message----- >From: Chris Csanady [SMTP:ccsanady@friley216.res.iastate.edu] >Sent: Thursday, December 05, 1996 6:47 AM >To: Peter Wemm >Cc: smp@freebsd.org >Subject: Re: make locking more generic? > > >>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?c=US%a=_%p=msft%l=RED-81-MSG-961205185533Z-4388>