Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!mips!cs.uoregon.edu!ogicse!zephyr.ens.tek.com!tektronix!percy!littlei!intelhf!ichips!ichips!glew From: glew@pdx007.intel.com (Andy Glew) Newsgroups: comp.arch Subject: Re: Atomic operations (Was Re: Living With Old Baggage) Message-ID: Date: 17 May 91 09:09:52 GMT References: <336@scorpio.gtephx.UUCP> <12741@pt.cs.cmu.edu> <1991May14.124017.23677@decvax.dec.com> Sender: news@ichips.intel.com (News Account) Organization: Intel Corp., Hillsboro, Oregon Lines: 74 In-Reply-To: kenton@abyss.zk3.dec.com's message of 14 May 91 12:40:17 GMT >|> In my synchronization survey I call this the "spinning on a >|> non-running processor" problem. So far, only the i860 has a general >|> solution to this problem, with its operation that blocks interrupts >|> for a short length of time from user mode. >|> > >BBN's latest Butterfly was designed with this feature, although I don't >think it got used. (Yes, I know they called it the TC-2000, not the >Butterfly 2. What do they know.) Locking was done with xmem instead. I have the TC2000 manuals, and I believe that I looked closely for any feature that avoids the "spinning on a non-running processor" problem. There does not seem to be any hardware support for this, although if I have missed it I would be happy to be corrected. If there is support for the "spinning on a non-running processor" problem in the BBN TC2000, I conjecture that it is purely in the OS in the form of something like gang scheduling. The TC2000 does have the ability to block interrupts, but not from user mode. Again, correct me if I am wrong. The TC2000 UNIX does provide a variety of atomic synchronization primitives, like compare-and-swap, fetch-and-add, fetch-and-or, etc. These are implemented as system calls. The system call blocks interrupts, XMEM is used for the hardware lock that excludes other processors, and the operation is performed. I think that what we are all interested in is a way of doing these forms of synchronization without system calls. Spinlocks on the TC2000 must be test-and-set spinloops. You can't even use a cache test to do a test-and-test-and-set spinloop. The TC2000 manual goes into great detail about adding delays to a test-and-set spinloop to reduce contention. By the way - MIPS' load-locked/store-conditional synchronization primitives might conceivably be used to block interrupts as well as providing atomic interprocessor RMWs. Question for MIPS: are interrupts blocked inside a load-locked/store-conditional sequence? Personal preference: it's better to separate the interrupt blocking and the atomic RMW functionality. [*] thanks to someone at BBN - if you want the synchronization features of your machine to be discussed in the December, 1991, edition of the synchronization survey, tell me about it now. "Telling me about it" can comprise email about the synchronization features, although spec sheets, users manuals, etc. are always preferred (mainly because half the things people have told me by email have been wrong). Send to: My email address is glew@ichips.intel.com My office phone is 503-696-4119 Office FAX: 503-648-7397 My mail address is Andy Glew Mail stop JF1-19 Intel Corporation 5200 NE Elam Young Parkway Hillsboro, OR 97124-6497 -- Andy Glew, glew@ichips.intel.com Intel Corp., M/S JF1-19, 5200 NE Elam Young Parkway, Hillsboro, Oregon 97124-6497 This is a private posting; it does not indicate opinions or positions of Intel Corp.