Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!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: 13 May 91 09:29:12 GMT References: <336@scorpio.gtephx.UUCP> <12741@pt.cs.cmu.edu> <14628@encore.Encore.COM> <1991Apr22.175410.9840@decvax.dec.com> <1991May2.201917.15062@dg-rtp.dg.com> <1991May6.113149.14531@decvax.dec.com> Sender: news@ichips.intel.com (News Account) Organization: Intel Corp., Hillsboro, Oregon Lines: 22 In-Reply-To: kenton@abyss.zk3.dec.com's message of 6 May 91 11:31:49 GMT >Once you've created a lock (with xmem) you can do almost anything within the >locked region of code without disabling interrupts. Including being preempted, leaving all the other processors spinning for a lock held by a process which is swapped out. Gang scheduling is only half a solution. 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. -- 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.