Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!mips!daver!ditka!zinn!decvax.dec.com!abyss.zk3.dec.com!kenton From: kenton@abyss.zk3.dec.com (Jeff Kenton OSG/UEG) Newsgroups: comp.arch Subject: Re: Atomic operations (Was Re: Living With Old Baggage) Message-ID: <1991May14.124017.23677@decvax.dec.com> Date: 14 May 91 12:40:17 GMT References: <336@scorpio.gtephx.UUCP> <12741@pt.cs.cmu.edu> Sender: usenet@decvax.dec.com (Usenet News System) Reply-To: kenton@abyss.zk3.dec.com (Jeff Kenton OSG/UEG) Organization: Digital Equipment Corporation - Nashua, NH Lines: 28 Nntp-Posting-Host: abyss.zk3.dec.com In article , glew@pdx007.intel.com (Andy Glew) writes: |> |> >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. |> Several postings have convinced me on this issue. |> |> 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. ----------------------------------------------------------------------------- == jeff kenton Consulting at kenton@decvax.dec.com == == (617) 894-4508 (603) 881-0011 == -----------------------------------------------------------------------------