Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!newstop!sun!amdcad!dvorak.amd.com!nucleus!peter From: peter@nucleus.amd.com (Peter Song) Newsgroups: comp.arch Subject: Re: MIPS LL & SC instrs Message-ID: <1991Jun14.204703.29648@dvorak.amd.com> Date: 14 Jun 91 20:47:03 GMT References: <373@orac.UUCP> Sender: Peter Song Organization: Advanced Micro Devices, Austin, TX Lines: 28 | >What are the circumstances where one has to use non-cacheable memory locations for any | >"meaningful" (meaningful being more than just the producer/consumer relationship) | >synchronization, given that LL/SC works only with cacheable locations? | | What if you had a non-cacheable, shared memory on the system bus. It is | possible to make a shared memory that links multiple systems to a single | coherent memory image. Not all the processors sharing the memory would | be on a single chassis. Let's not get confused with the mechanisms for synchronization and the mechanisms for cache coherency - two are not the same. All copies of a synchronization variable (ie. the location used to achieve some form of synchronization) must be kept consistent at all times, whereas all copies of a shared location not used for synchronization may be kept consistent "only when necessary." The less efficient it is to notify a change of shared data to all its copies, less often a system SHOULD try to maintain consistency. Unfortunately, most shared memory multiprocessors do not distinguish between synchronization variables and shared data, and apply the same consistency rules to both. | | If you had a bus that depended on snooping/snarfing to maintain the | cache-coherence, you would have to mark this shared memory as non-cacheable. | (It can be modified without a local bus access being generated, so there | is nothing to snoop/snarf.) Have you heard of "shared" bit (circa 1985 or earlier)? S. Peter Song - 29K Advanced Processor Development - Advanced Micro Devices peter@nucleus.amd.com (800) 531-5202 x54818