Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!elroy.jpl.nasa.gov!decwrl!ucbvax!hplabs!hpda!hpcupt1!hpisod2!dhepner
From: dhepner@hpisod2.HP.COM (Dan Hepner)
Newsgroups: comp.arch
Subject: Re: Re: Shared Memory
Message-ID: <13910015@hpisod2.HP.COM>
Date: 8 Feb 90 19:29:18 GMT
References: <81.25d07596@waikato.ac.nz>
Organization: Hewlett Packard, Cupertino
Lines: 21

From: ccc_ldo@waikato.ac.nz
>The idea was that, by complicating the instruction
>sequence necessary to do the write, you lessen the chance of a wild program
>corrupting the log.

>How about if you don't have a subroutine to do the write, but only in-line
>code? Of course, this would lead to even more strange behaviour if you
>should accidentally branch to the code.

The way to address this potential is with software design, not through
attempts to make the instruction sequences tougher to land in.

Reasonably designed software would almost certainly encounter a
failed assertion before actually corrupting the log.

ccc_ldo correctly notes the lack of fundamental difference between memory 
and disk for protecting logs from corruption due to software bugs.  Buggy 
software, or maybe even a perfect wild branch, could corrupt the log 
regardless of if it's written to memory, disk, or stone.

Dan Hepner