Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!apple!mips!zalman From: zalman@mips.com (Zalman Stern) Newsgroups: comp.arch Subject: Re: Atomic operations Keywords: atomic synchronization MIPS Message-ID: <3501@spim.mips.COM> Date: 15 May 91 00:48:44 GMT References: <19305@sunquest.UUCP> Sender: news@mips.COM Distribution: usa Organization: MIPS Computer Systems, Sunnyvale, California Lines: 27 Nntp-Posting-Host: dish.mips.com In article <19305@sunquest.UUCP> terry@venus.sunquest.com (Terry R. Friedrichsen) writes: [How do you do atomic locking using the MIPS-I instruction set (i.e. R[23]000).] Either operating system support or extra hardware. Here are a few design points: MIPS RISC/os (and Ultrix and others) provide a system call which masks interrupts and does a test-and-set like operation. (You can also use SysV semaphores of course, but there are many problems there.) Mach traps an illegal instruction to do the operation. This is faster than a system call. They also claim to have a completely user space algorithm that works even with preemption. I don't know the details. SGI provides hardware on their multi-processor machines. This involves special memory (a section of) which is mapped into a processes address space via a system call. A load from the memory location tries to acquire the lock and returns success/or failure as the loaded value. A store clears the lock. DEC SRC is doing work where the OS and compiler cooperate such that the OS can tell when a user program was trying to acquire a lock. If preemption occurs during a lock operation, the OS allows it to complete (or completes the operation itself, I'm not sure). (This is for their Topaz OS not UNIX.) -- Zalman Stern, MIPS Computer Systems, 928 E. Arques 1-03, Sunnyvale, CA 94088 zalman@mips.com OR {ames,decwrl,prls,pyramid}!mips!zalman (408) 524 8395 "So you see, what we can do is try something new / If you're crazy too I don't really see why can't we go on as three" Triad By David Crosby