Date: Thu, 5 Dec 1996 16:49:30 -0800 From: Thomas Pfenning <thomaspf@microsoft.com> To: "'Steve Passe'" <smp@csn.net> Cc: "'Chris Csanady'" <ccsanady@friley216.res.iastate.edu>, "'Peter Wemm'" <peter@spinner.dialix.com>, "'smp@freebsd.org'" <smp@freebsd.org> Subject: RE: make locking more generic? Message-ID: <c=US%a=_%p=msft%l=RED-81-MSG-961206004930Z-6829@INET-04-IMC.itg.microsoft.com>
next in thread | raw e-mail | index | archive | help
Hmm, but xchgb actually writes a new value into the cache line on each spin and dirties the cache line? So you are saying, the cache coherence protocol is smart enough to recognize it is the same value and does not actually require an update of the cache in a remote CPU spinning on the same lock. Or is it the xchgb instruction which does not write an 0xff if it is already there? The other thing I don't quite understand is the use of an atomic memory operation for the unlock. Cheers Thomas >-----Original Message----- >From: Steve Passe [SMTP:smp@csn.net] >Sent: Thursday, December 05, 1996 4:22 PM >To: Thomas Pfenning >Cc: 'Chris Csanady'; 'Peter Wemm'; 'smp@freebsd.org' >Subject: Re: make locking more generic? > >Hi, > >> 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. > ... >> >>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 > >no, > > %al has 0xff in it, > the initial locked value is 0xff > each spin puts %al (ie 0xff) into bootlock and bootlock into %al > so bootlock remains 0xff until the unlock function is called > > the unlock functiom puts 0x00 into %al, then does the xchgb, putting > the 0x00 into bootlock, and tossing the contents of %al as it returns. > > so the next spin on the lock by ONE AP puts %al (0xff everytime) into > bootlock, and gets %al filled with the 0x00 placed there by unlock. > > the other APs get the 0xff placed there by the one successful xchgb > that the 1st AP made. > >-- >Steve Passe | powered by >smp@csn.net | FreeBSD >
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-961206004930Z-6829>