From: maxtal@extro.ucc.su.OZ.AU (John MAX Skaller)
Subject: Re: Persistance Problem Solved by Memory-Mapped Files?
Organization: MAXTAL P/L C/- University Computing Centre, Sydney
Date: Mon, 5 Oct 1992 07:28:32 GMT

In article <1aiknfINNf0o@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>In article <1992Oct1.144640.14630@ucc.su.OZ.AU> maxtal@extro.ucc.su.OZ.AU (John MAX Skaller) writes:
>>In article <1a9uh5INN4o4@early-bird.think.com> barmar@think.com (Barry Margolin) writes:
>>>In article <d8_p1zq.feustel@netcom.com> feustel@netcom.com (David Feustel) writes:
>>>.  Pointers between objects have to be replaced with offsets from
>>>the base of the file.  
>>
>>	You're making a hidden assumption here: you're perhaps too familar
>>with linear address machines. 
>
>I cut my system programming teeth on Multics, and later moved on to Lisp
>Machines.

	Sorry! The fact is, it is myself that is too familiar
with single CPU systems (see below), so when I think about
persistence I'm the one making assumptions.

>
>>			       On the 386 one could map a file to
>>a segment. A pointer already consists of a selector for the segment (file)
>>and an offset into the segment (file). Such pointers would not have
>>to be 'replaced' since they already have the right form. The problem is
>>reduced to associating selectors with files consistently.
>
>That may be non-trivial, unless there's some kind of global mapping of
>segment selectors to files, so that the selectors have consistent use
>across processes.  In a networked environment this could be tricky to
>guarantee.

	Of course. I said the problem was reduced to the selector
management, which is not to say the resulting problem is trivial.
And of course, if you add 'network' requirements, you are again
adding a whole level. The 386 architecture doesn't have anything
that will help much with that.

>
>>>Also, memory-mapped files only work if all the cooperating processes share
>>>a file system that supports it.  I'm not sure how reliable writing to
>>>memory-mapped files is when NFS is in use (I don't think each write to the
>>>mapped memory results in an NFS write, so multiple copies of the file could
>>>get out of sync).
>>
>>	Again, on the 386 this is trivia, since the VM system buffers the
>>files exposing the same PHYSICAL memory to all processes. 
>
>Not if they're on different machines on the network, which don't share any
>physical memory.  If machine1 and machine2 both map a file on serverA,
>writes to the memory on machine1 may not be propogated to serverA
>immediately, and even if they are, they may not be propogated to machine2
>immediately.  As I said, it depends on the file system type and
>implementation.

	Yes. In fact even 2 cpus on the same bus may have cache
consistency problems. In fact even one cpu and anothe bus master
like a DMA channel from the disk!

	But the problem above exists even if the physical memory
is shared and updated immediately, that is, you still need
locking to ensure consistency. In a networked situation the 
locks could also ensure re-caching.

-- 
;----------------------------------------------------------------------
        JOHN (MAX) SKALLER,         maxtal@extro.ucc.su.oz.au
	Maxtal Pty Ltd, 6 MacKay St ASHFIELD, NSW 2131, AUSTRALIA
;--------------- SCIENTIFIC AND ENGINEERING SOFTWARE ------------------