Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!rpi!unix.cie.rpi.edu!philhowr From: philhowr@unix.cie.rpi.edu (Bob Philhower) Newsgroups: comp.arch Subject: Re: Instruction (dis)continuation Message-ID: <7088@rpi.edu> Date: 5 Sep 89 18:28:21 GMT References: <1989Aug24.215104.156@mentor.com> <231@ssp1.idca.tds.philips.nl> <2345@oakhill.UUCP> <204@bbxeng.UUCP> <5990@pt.cs.cmu.edu> <205@bbxeng.UUCP> <265@gp.govt.nz> <45180@bbn.COM> <3267@scolex.sco.COM> Sender: usenet@rpi.edu Reply-To: philhowr@unix.cie.rpi.edu.UUCP (Bob Philhower) Organization: CIE, Rensselaer Polytechnic Institute, Troy, NY Lines: 19 In article <3267@scolex.sco.COM> seanf@sco.COM (Sean Fagan) writes: >In article <45180@bbn.COM> dswartz@BBN.COM (Dan Swartzendruber) writes: > >Now, my point: how about shared memory? (SysV-type shared memory, not >multi-processor-type shared memory.) With instruction restart, the value in >$300 could have changed, while, with instruction continuation, it doesn't >matter. How do various OS's and hardwares handle it? I contend that the possibility of the source location being changed during a page fault on the destination is a non-issue. If there had been no page fault, the "old" value would have been written. Designers who need to worry about this possibility should really be thinking about some sort of semephore to prevent writing during a read. Robert Philhower (philhowr@unix.cie.rpi.edu) Rensselaer Center for Integrated Electronics CII 6111 / Rensselaer Polytechnic Institute / Troy, NY 12180 / USA