NetNews Usenet Archive 1993 #1/NN_1993_1.iso/spool/comp/sys/isis/362

Text File | 1993-01-05 | 3.6 KB | 70 lines

Newsgroups: comp.sys.isis
Path: sparky!uunet!usc!rpi!batcomputer!cornell!ken
From: [e-mail] (Ken Birman)
Subject: Re: Question I got about use of shared memory in Isis
Message-ID: <[e-mail]>
Organization: Cornell Univ. CS Dept, Ithaca NY 14853
References: <[e-mail]> <[e-mail]>
Date: Tue, 5 Jan 1993 14:16:06 GMT
Lines: 59

In article <[e-mail]> [e-mail] (Gautam H. Thaker) writes:
>[... may see Isis using shared memory communication on]
> MACH based systems (OSF/1 ?) in the next 6-12 months. Since
>Solaris 2.x is also a major commercial system, is any aggressive use
>of shared memory by ISIS likely for that OS in the near future?
>Is there anything equiv. to MACH IPC on Solaris to let you do this?

Not that I know of.  I'll ask Jacob Levy about this.  We are happy to
use OS support for efficient communication where it exists, but I am
hesitant to have Isis itself try and implement some sort of shared
memory communication scheme where the OS only has mapped files or
something.

If some student out there wants a project, it might be interesting to
use the isis_transport interface to experiment with a shared memory
communication approach for Isis using mapped files.  I would wait for
V2.0.8 on this (available quite soon) but since I use this interface
myself for ipmcast and there is an example of how it works based on
tcp channels in the manual, it should be feasible.

If someone does this, and the results are positive, we could consider
supporting this as part of the system -- or at least give people copies
of it...

>   As for Isis, we don't do anything special about this, but in our
>   manual, section on "examples", you will find an example of how to
>   use shared memory within a group of processes all of whose members
>   reside on the same machine.  So, it isn't hard to exploit shared
>I need to take another look at this option, but at least some of
>our groups members are on different machines.

Shared memory on a network is a real loser (in my opinion, and I don't
mean on a MIMD parallel processor).  So, I would focus on the single
machine case, or perhaps the MIMD case if you have a KSR machine or
something of that flavor.

>BTW, do you see any impact to UI ATLAS arch. due to the
>Novell purchase of USL?

GE is very into politics... well, yes, I do see a substantial impact here.
The key issue for UI Atlas and Vision 2000 will be the extent to which
the OSF member companies buy in to that whole direction.  Even owned by
Novell, USL will continue to sell SVR4 and subsequent systems and if they
have customers who are happy, UI Atlas and Vision 2000 will have an
important impact.   Novell is focused on something called Univell which
(if I understand it) is a way to link your UNIX workstations to the Novell
networking environment -- this gives you a shared file system, email and
memo capabilities, and so forth.  I don't understand what the long term
strategy for Univell might be, but I doubt that UI Atlas has any particular
importance in that effort.  Perhaps, however, the UI working groups in
kernel architecture, high availability, distributed tools, and object
orientation will produce sufficiently impressive recommendations so that
Univell will sign on, too.

Anyhow, thats just my guess.  We all read the same newspapers...
--
Kenneth P. Birman                              E-mail:  [e-mail]
4105 Upson Hall, Dept. of Computer Science     TEL:     [phone] (office)
Cornell University Ithaca, NY 14853 (USA)      FAX:     [phone]