From owner-freebsd-smp Thu Dec 5 17:49:37 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id RAA18572 for smp-outgoing; Thu, 5 Dec 1996 17:49:37 -0800 (PST) Received: from INET-01-IMC.microsoft.com (mail1.microsoft.com [131.107.3.41]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id RAA18566 for ; Thu, 5 Dec 1996 17:49:35 -0800 (PST) Received: by INET-01-IMC.microsoft.com with SMTP (Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63) id <01BBE2D4.9A72A790@INET-01-IMC.microsoft.com>; Thu, 5 Dec 1996 17:49:03 -0800 Message-ID: From: Thomas Pfenning To: "'Steve Passe'" Cc: "'Chris Csanady'" , "'Peter Wemm'" , "'smp@freebsd.org'" Subject: RE: make locking more generic? Date: Thu, 5 Dec 1996 17:49:23 -0800 X-Mailer: Microsoft Exchange Server Internet Mail Connector Version 4.0.994.63 Encoding: 59 TEXT Sender: owner-smp@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Actually you can do something about it which does not cause any contention on the bus doing the update protocol and even grants the lock in fifo order. However, the lock actually transforms into a linked list and you spin on memory location in your local cache, so you want to make it aligned to cache lines. Mellor-Crummey and M. Scott, Algorithms for scalable synchronization on shared-memory multiprocessors; ACM Trans. Computer Systems, 9(1):21--65 (1991) Cheers Thomas >-----Original Message----- >From: Steve Passe [SMTP:smp@csn.net] >Sent: Thursday, December 05, 1996 5:07 PM >To: Thomas Pfenning >Cc: 'Chris Csanady'; 'Peter Wemm'; 'smp@freebsd.org' >Subject: Re: make locking more generic? > >> 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? > >oh-oh, I didn't read close enough (alot of mail has backed up lately). >forget what I said... > >cache, I couldn't say, it might have a bad effect but what can you do >about it? a blocking lock as oppossed to a spin-lock? I think the theory is >that the collissions are statistically so short that anything more complex >would be a loosing situation. > >---- >> The other thing I don't quite understand is the use of an atomic memory >> operation for the unlock. > >the atomic move may or may not be necessary. since its a byte there is >no chance a misaligned lock being written in 2 bus operations. anyone know? > >-- >Steve Passe | powered by >smp@csn.net | FreeBSD > >-----BEGIN PGP PUBLIC KEY BLOCK----- >Version: 2.6.2 > >mQCNAzHe7tEAAAEEAM274wAEEdP+grIrV6UtBt54FB5ufifFRA5ujzflrvlF8aoE >04it5BsUPFi3jJLfvOQeydbegexspPXL6kUejYt2OeptHuroIVW5+y2M2naTwqtX >WVGeBP6s2q/fPPAS+g+sNZCpVBTbuinKa/C4Q6HJ++M9AyzIq5EuvO0a8Rr9AAUR >tBlTdGV2ZSBQYXNzZSA8c21wQGNzbi5uZXQ+ >=ds99 >-----END PGP PUBLIC KEY BLOCK----- >