Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!think.com!cass.ma02.bull.com!mips2!bbn.com!star-trek!lkaplan From: lkaplan@star-trek.bbn.com (Larry Kaplan) Newsgroups: comp.arch Subject: Re: Atomic operations (Was Re: Living With Old Baggage) Message-ID: <6729@archive.BBN.COM> Date: 28 May 91 15:18:49 GMT References: <336@scorpio.gtephx.UUCP> <12741@pt.cs.cmu.edu> <1991May14.124017.23677@decvax.dec.com> Sender: news@bbn.com Reply-To: lkaplan@BBN.COM (Larry Kaplan) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 75 In article glew@pdx007.intel.com (Andy Glew) writes: >>|> 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. > >The TC2000 does have the ability to block interrupts, but not from >user mode. Again, correct me if I am wrong. At one time it was thought that the TC2000 could give the user the option of blocking out interrupts via something called a user augmentations register available in user space. This turned out to not work well enough for O/S related reasons. Instead, the way we currently deal with the problem is to not worry about the interrupts themselves. They are not going to cause user mode locks any problems since no interrupt code is ever going to take a user lock. The real problem, as stated before, is getting context switched as a result of an interrupt (e.g. a scheduler interrupt). To solve this, we provide various system calls for the user to disable preemption. Look at user_nopreempt(2). This allows XMEM based locks to avoid the "spinning on a non-running processor" problem. >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. This is not exactly correct. System calls are used for these atomic operations, but they are of the "fast trap" kind where no context is saved and no interrupts or other exceptions are handled during the call. Each operation is fairly short so this works well. Also, XMEMs are NOT used to implement any of these operations. The TC2000 hardware has true locking semantics on its memories and interconnection network. This works by locking a memory when a locked operation starts, and keeping it locked until the entire operation is complete. These are activated automatically by a user mode XMEM and manually in the kernel to do the other atomic operations. The general sequence for a fetch and op is: Do preparatory work like checking that the memory is resident Disable interrupts Set lock bit (lock not taken until next real memory reference) Read location (sets lock) Operate on data in registers Write result Clear locks Return original value More details of the locking protocol are available in "Inside the TC2000". > I think that what we are all interested in is a way of doing these >forms of synchronization without system calls. True enough. #include _______________________________________________________________________________ ____ \ / ____ Laurence S. Kaplan | \ 0 / | BBN Advanced Computers lkaplan@bbn.com \____|||____/ 70 Fawcett St. (617) 873-2431 /__/ | \__\ Cambridge, MA 02238