Path: utzoo!utgpu!water!watmath!clyde!ima!cfisun!palladium!nw From: nw@palladium.UUCP (Neil W.) Newsgroups: comp.sys.amiga Subject: Re: Another 68020 difference Summary: BSET *is* single-processor atomic, in absence of MMU Message-ID: <531@palladium.UUCP> Date: 25 Jun 88 14:50:03 GMT References: <8806240024.AA11802@cory.Berkeley.EDU> Reply-To: nw@palladium.UUCP (Neil W.) Organization: Epoch Systems, Marlborough, MA Lines: 63 In article <8806240024.AA11802@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > > A friend of mine got caught by this one: > > BSET is atomic, right? OR.w #1,memory? > > wrong > > Guess what? The 68020 has no compunction for interrupting an > instruction in the middle of its execution. > This isn't correct, unless I misunderstand what you are saying. The 68020 samples interrupts generated by external devices *only* on instruction boundaries; you will never see an interrupt handler invoked in the middle of read and write cycles of any instruction. On the Amiga, you will *never* see a process switch occur in the middle of such an instruction. One exception :-) to this rule is the Bus Error exception, aka "page fault" on systems with an MMU. The Bus Error exception can in fact occur on *any* bus cycle. Thus, this sequence of operations is possible: - BSET reads memory - BSET modifies bit internally - BSET writes memory -- but wait! the write fails due to bus error, because the page has been marked read-only and this is a UNIX box with copy-on-write fork :-) - UNIX kernel copies the page, marks it writable, and is preparing to return to your process. At this point, if an external interrupt occurs, the interrupt handler would in fact be able to modify the very same location that the BSET instruction was trying to modify. If this were to happen, then when the kernel returns from the bus error exception, the write cycle of the BSET instruction will pick up where it left off -- any modifications to the location made by the interrupt handler may in fact get trashed. This happens because the bus error exception works on a cycle-by-cycle basis, not on an instruction-by-instruction basis. A similar thing can happen with signal handlers on UNIX boxes. Signal handlers get invoked by Berkeley-derived UNIX in the tail end of the processor exception code. Thus, it is possible that a naive port of the vax "trap.c" code to a 680x0 box might make it possible for a user signal handler to be invoked "in the middle" of an instruction. I consider this to be a bug in the kernel, because it exposes a macro-inconsistent state of the machine to the user process signal handler. Things get especially strange if the faulted instruction was a JSR that has to grow the stack. > So all those supposedly atomic single-instruction operations people >have probably been doing, and not surrounding them with Forbid()/Permit(), >create windows of vulnerability if you've got a 68020. I don't think so, unless someone has ported a buggy UNIX implementation to their Amigas :-) -- Neil Webber / Epoch Systems, Marlboro MA / (617) 481-3717 {harvard!cfisun, linus!alliant}!palladium!nw