Article View: comp.arch
Article #22206Re: Shared Memory
From: ccc_ldo
Date: Wed, 07 Feb 1990 14:46
Date: Wed, 07 Feb 1990 14:46
15 lines
1213 bytes
1213 bytes
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.
Technical Details
Message-ID:
<81.25d07596@waikato.ac.nz>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!aplcen!samsung!munnari.oz.au!comp.vuw.ac.nz!kaukau.comp.vuw.ac.nz!waikato!virtue!ccc_ldoReferences:
<13910004@hpisod2.HP.COM> <13910007@hpisod2.HP.COM> <7695@pt.cs.cmu.edu>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!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