Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!agate!saturn!mcvax!cs.tcd.ie!horn@uunet.UU.NET From: mcvax!cs.tcd.ie!horn@uunet.UU.NET (Chris Horn) Newsgroups: comp.os.research Subject: Re: Question for the week -- distributed Multics? Message-ID: <6345@saturn.ucsc.edu> Date: 10 Feb 89 11:17:26 GMT Sender: usenet@saturn.ucsc.edu Organization: Computer Science Department, Trinity College, Dublin Lines: 36 Approved: comp-os-research@jupiter.ucsc.edu We also have been doing work on distributed shared memory for about the last 18 months. Our basic approach is that when an application requires access to a "segment", it can either be faulted in locally (possibly from a remote store, ie across the net) or the process can "diffuse" to use the segment at a remote site. When synchronous remote execution occurs, the same thread of control is involved at both the calling and called site - ie threads of control may be distributed. There are primitives to for example create, suspend, resume, kill such threads, independently of where current execution site is. By default, there is only at most one updateable image of a segment mapped into virtual memory anywhere in the network. Threads which simultaneously access this segment may therefore be diffused to reach this common site. Segments also are persistent by default - ie they behave as memory mapped updateable files. Defaults can be over-ruled to eg disable persistence (and so get a segment which behaves like a UNIX data/bss region), or support copy-on-write (thus disabling sharing updates in virtual memory, and useful for eg UNIX forking). Whether diffusion or remote fetch is used when a segment is first touched is under programmer/compiler/OS policy control. The work is under the auspices of the Esprit Comandos project, and our prototype was demonstrated on NS32332s at the last Esprit conference in Brussels (nov 88). We are currently improving and gaining experience with the prototype, and are porting to Vax. Our colleagues at IMAG grenoble have prototyped aspects of the system as a series of libraries on top of UNIX SysV (with bsd extensions) without kernel changes; our colleages at INESC lisbon have prototyped on PC/AT compatibles. Chris Horn --------- horn@cs.tcd.ie Dept Computer Science, Trinity College, IRL-Dublin 2