🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #22206

Re: Shared Memory

#22206
From: ccc_ldo
Date: Wed, 07 Feb 1990 14:46
15 lines
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_ldo
References: <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