root@sbcs.sunysb.edu (SBCS Systems Staff) (04/24/88)
In article <9132@agate.BERKELEY.EDU>, pete@violet.berkeley.edu (Pete Goodeve) writes: > > memory box we have in front of us now. I'm NOT saying we shouldn't look > forward to multiprocessor (like Transputer?!) distributed systems, but we > mustn't hamstring local processes by insisting that they obey all the > restrictions of that environment. Actually Peter, given the MMU's that will be present in future designs copying is not much of an evil at all (MACH). I would guess that since messages tend to be small (eg mouse movements generate a lot of small messages), copying is not much overhead even on a non MMU system. Side comment: if we're thinking speed, then the noun "Transputer" doesn't belong in this article. The T414/T800 have to be one of the slowest, most expensive CPU families I've used. > In fact the Port/Message environment built into the Exec is already far > more suitable. We can address messages to ports rather than to processes > (as V does) and we can use meaningful strings, rather than 32-bit IDs, to I didn't propose that we limit ourselves *just* to the IPC semantics presented by V. I had suggested that V be studied as a successful attempt at constructing a message based system. Agreed that we would want to drop the process -> process, synchronous semantics of V. The issue of how naming is handled at the lowest levels is just a matter of taste. Sure with proper alignment you probably can derive almost the same performance using short strings or 32 bit ID's. I would prefer the 32 bit ID's, as once the protocols are up and running I don't want to spend packet space on names (plus we would not violate the VMTP standard for non existent or trivial gains). It makes far more sense to specify a nameserver to go ASCII -> ID once than have to pay on a per packet basis. > Where we really part company with V, though, is in our approach to > accessing data. In a distributed system, you usually don't have direct > access to a block of data at a remote site, so V's message protocol is > based on COPYING. Further, copying can only happen during "rendezvous" (to > borrow a term from a DoDdery language) -- i.e. while the sender is > SUSPENDED. If you've been following the discussion on the net, though, Deviate from the suspended semantics. No problem. > you'll realize that one of our main concerns has been speed: it is much > better to pass the receiver process a pointer to the data (and permission > to play with it) than to copy large blocks; saves memory too -- especially > when you're passing bit maps around. Yes speed is a concern. I would hope that the FOCUS of the design is on extensibility. With 680[23]0's soon, home RISC on the horizon, the only way you'll avoid speed is by coding the thing in Prolog :-). > Past articles in this discussion have dealt at fair length with the > different constraints on local and network message passing. There are lots > of things that are reasonable to pass to a local process, but that make no > sense over a network -- things like port addresses, file locks, and file > handles. And think of a linked list: locally, all you have to do is pass > a pointer to the head, but for shipping out on a net you have to > disassemble it, send it item by item, and reassemble it (with local > pointers) at the other end. Yes, but the point is that if we get people used to a non local model of communication, we still get to play local optimizations in a transparent way, and at the same time get something that may be used in a networked environment. > > We shouldn't reinvent the wheel if we don't have to. [.....] > Yes, but you don't want to put a tractor wheel on a bike... And of course we should be able to find out that tractor wheels on bicycles are a Bad Thing by reading, not by implementing :-). Evaluating various design decisions is hardly ever as obvious as the example you've suggested. > > our primitives). This method must allow for client and server to be on > > different machines. > See the discussion above. I suspect a "distributed IPC kernel" on the > Amiga will take the form of a local server that knows how to make messages > suitable for net transmission, and complains if it can't. Our IPCMessage > format is designed to make this possible even though the server doesn't > know the nature of the message data. I doubt you can do this transparently. Example: process A sends a handle to local screen memory to process B. What to I do if the size of screen memory passed is implicitly assumed by prior agreement of A&B and is not sent as part of the message? > BTW -- Can we now move this discussion over to comp.sys.amiga.tech, please? > ...At least when we start any new threads. Done. Rick Spanbauer SUNY/Stony Brook
kgschlueter@orchid.waterloo.edu (Kevin Schlueter) (04/24/88)
In article <9132@agate.BERKELEY.EDU> pete@violet.berkeley.edu.UUCP (Pete Goodeve) writes: > >There have been a couple of postings recently advocating Cheriton et al's >"V kernel" as a basis for our IPC standard <12379@orchid.waterloo.edu> ><1135@sbcs.sunysb.edu> <12388@orchid.waterloo.edu>. > >Much as I admire the "V" system, its origin and rationale are quite >different from the environment that we expect to be working in, so the >protocols and primitives it uses aren't appropriate for us. A distributed >environment has very different constraints from the multi-process/common- >memory box we have in front of us now. It is terribly important to plan ahead for the future when designing standards. Add a network card to the Amiga and you've got all the hardware you need for a distributed system. Add an MMU to a machine and run each process in its own address space and you've got the analogue of a distributed system, at least as far as message passing primitives are concerned (ie shared memory is potentially no longer available). I don't think the either of the above two scenarios are that far off for the Amiga. Hence, failure to take them into account would needlessly cripple IPC. There is no doubt that message copying is less efficient than the current scheme of passing messages by reference (well, you know what I mean!). Fine. Use EXEC primitives to communicate between the tasks (or processes) that make up ONE PROGRAM. Use IPC to communicate across programs. I think that this gives us the best of both worlds. Granted, it makes no sense for some services to be provided by a remote machine (display of IFF files, for example). Perhaps servers should specify whether their services are available across machines when they register with the name server. However, it will make sense to allow for servers and clients to be on different machines in most cases. This is alot like saying that multitasking is indispensible to someone who has never used multitasking. >> We shouldn't reinvent the wheel if we don't have to. [.....] > Yes, but you don't want to put a tractor wheel on a bike... I think we've really got a tractor with bike wheels. Let's go all the way and push the Amiga back into the leading edge of computing.