Path: utzoo!attcan!uunet!aplcen!samsung!munnari.oz.au!comp.vuw.ac.nz!kaukau.comp.vuw.ac.nz!waikato!virtue!ccc_ldo
From: ccc_ldo@waikato.ac.nz
Newsgroups: comp.arch
Subject: Re: Shared Memory
Keywords: fault tolerance messages shared_memory
Message-ID: <81.25d07596@waikato.ac.nz>
Date: 7 Feb 90 14:46:21 GMT
References: <13910004@hpisod2.HP.COM> <13910007@hpisod2.HP.COM> <7695@pt.cs.cmu.edu>
Lines: 15

In <7695@pt.cs.cmu.edu>, lindsay@MATHOM.GANDALF.CS.CMU.EDU (Donald Lindsay)
mentions, as a drawback of shared memory, the example where a commit log
for reliable transactions might be written to battery-backed memory
instead of to disk. 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.

Lindsay says this works, but "only partially", as the wild program can
still corrupt the log by calling the subroutine that knows how to write to it.

It seems to me the same objection applies to an on-disk 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.