ken@gvax.cs.cornell.edu (Ken Birman) (05/10/89)
A few people have asked me how V1.2 of ISIS will differ from V1.1.
I've decided to post the following summary of changes as a way of
responding. We are just entering the alpha stage of testing V1.2,
so a real release is still 4-6 weeks off. I'll be happy to accept
beta-test sites when the time comes, but don't volunteer just yet.
I would be interested in comments and feedback on the proposed changes.
There is still time to get your favorite feature added to the system,
or even to see you least favorite bug fixed. I don't have a list
of bugs fixed, but V1.2 is certainly more robust than V1.1 in many
ways. Still, if you know of a bug and haven't reported it to me, don't
count on us having fixed it. We've fixed everything people have told
us about.
Most of the "META" software we have described in recent papers will
not be released until later this year, probably in ISIS release V2.0
(whenever that happens).
Summary of changes to ISIS:
One very visible change:
o address structure no longer passed by value/returned by value
Affects almost all ISIS system calls.
o The output formats that required structure passing by value
are no longer permitted: %a,%e,%p and %b. Use %A...%B instead.
A new format, %X[const] has been added, for fixed-size arrays,
and %-x, %+x is now supported for all data types.
o SUN OS users will need to link to library "lwp" now.
Many new features and other changes:
o Manual revised, "man" pages for most ISIS system calls provided
o Fortran->isis now works, but only tested from F77 on SUN3/OS4.0
o Allegro->isis now supported
o Ported to Apollo UNIX (10.1), MACH
o Uses available lightweight process mechanism if possible:
SUN LWP, MACH Cthreads, Apollo tasks. Stack limit can
hence be eliminated, and arbitrary mixtures of native and
ISIS tasking are permitted. Pre-emptive tasks are supported
(but only one task can be actively using ISIS mechanisms at a time)
o isis_mainloop() no longer mandatory; can use isis_acceptevents instead
o isis_accept_events: now requires a flag
o BYPASS communication facility gives huge speedup, supports
specialized user-provided transport protocols
o isis_entry_stacksize(enum, size): sets stack size for specific entry
o Suntools users should call isis_suntools_init(port-no) instead
of isis_init(port-no)
o isis_input_sig: does a t_sig when input is available
o isis_signal_sig: does a t_sig when signal is received
o isis_chwait, isis_chwait_sig: does callback/signal when a child terminates
A few things to be aware of:
o SUN OS users will need to link to library "lwp" now.
o "exit()" may not do what you expect!
Details:
o Manual revised, "man" pages for most ISIS system calls provided
This speaks for itself.
o address structure no longer passed by value/returned by value
This affects almost all ISIS system calls, but because the
change is so pervasive, most programs can be fixed by changing
declarations from `address' to `address*'. For example,
say you used to write:
...
address gaddr, my_server;
gaddr = pg_lookup("group");
bcast(gaddr, HELLO, "%a", my_address, 1, "%a", &my_server);
In ISIS V1.2 you would code this as:
address *gaddr_p, my_server;
gaddr_p = pg_lookup("group");
bcast(gaddr_p, HELLO, "%A[1]", &my_address, 1, "%a", &my_server);
If the server used to do this:
if(addr_ismine(mgv->gv_members[0]))
reply(mp, "%a", my_address);
Now it would be changed to this:
if(addr_ismine(&mgv->gv_members[0]))
reply(mp, "%A[1]", &my_address);
[ Comment: we did this because passing of structures by value ]
[ was just not portable. Too many problems were caused by this ]
[ feature, and we lost too much time supporting it... ]
One issue to be aware of is that address pointers may not
be "stable" in all cases:
o pointers returned by msg_getsender, msg_getreplyto, etc. point
into the message and become undefined if the message is deleted.
The same comment applies when you use "%-a" in msg_get.
o pointers returned by pg_join, pg_subgroup point to a
structure that remains valid as long as you remain in the group.
pg_leave will invalidate these pointers
o pointers returned by pg_lookup on groups to which you don't
belong are copied into a safe place and saved indefinitely.
If you have a space problem call addr_free(addr_p) and ISIS
will get rid of this small space using a ref counter scheme.
We added casts so that calls to addr_cmp, addr_ismine, etc.,
and to bis(), bit(), bic(), bclr(), bisv() will probably not
compile if the argument is passed by value instead of by ref.
o The output formats that required structure passing by value
are no longer permitted: %a,%e,%p and %b. Use %A...%B instead.
However, %a.. can still be used on input (in msg_get), because
this does not require by-value argument passing for us to support.
A new format, %X[const] has been added, for fixed-size arrays,
and %-x, %+x is now supported for all data types. We use %A[1]
and %-a in places where we used to use %a on output.
There are some examples of this above. Notice that if
you used to say
msg_put(mp, "%a", addr);
you can change this fairly easily to
msg_put(mp, "A[1]", addr_p);
o Fortran->isis now works, but only tested from F77 on SUN3/OS4.0
The basic interface is the same, but you include "fisis.h"
(name your source file myfile.F to get the C preprocessor to
run) and omit the underscore character everywhere. However,
some care must be taken with address variables. See the
new manual section on this subject.
o Allegro->isis now supported
As for fortran, the basic interface is the same, but you'll
need to read the manual section to take advantage of this port.
o Ported to Apollo UNIX (10.1), MACH
We've only run the MACH port on NEXT machines, but it seems
quite solid on this hardware. It uses Cthreads and should
port to other MACH versions without changes.
o Uses available lightweight process mechanism if possible:
SUN LWP, MACH Cthreads, Apollo tasks, Allegro processes. Stack limits
depend on the native mechanism, and arbitrary mixtures of native and
ISIS tasking are permitted. Pre-emptive tasks are supported
(but only one task can be actively using ISIS mechanisms at a time)
That is, tasks can be run pre-emptively now, but a task
that wants to enter ISIS or that ISIS starts (including
callback tasks) will hold a mutual exclusion lock called
isis_mutex. Thus, ISIS itself continues to do things
non-preemtively, but you can exploit true preemption in the
rest of an application (say, for cursor tracking) provided
the high priority tasks don't call into ISIS.
You can mix native and ISIS task calls arbitrarily now.
ISIS emulates its own t_fork, etc, using native calls when
possible.
SUNOS users will need to link to the library "-llwp". Also,
note that ISIS uses a define to alias "exit" to "_exit"
under SUNOS, because the semantics of "exit" were changed by
SUN in a bizarre way that might surprise you otherwise.
[ Comment: these changes eliminate the assembler code from ISIS! ]
o isis_mainloop() no longer mandatory; can use isis_accept_events instead
o isis_accept_events(flag): The flag is new (and required). 0 operates
asynchronously, ISIS_BLOCK means "don't return until something has
been done."
The way that ISIS runs the task subsystem has been substantially
changed (enhanced, actually). The core routine is now the one
called isis_accept_events, which is told either to block or to
run asynchronously. In the former case, the call will return when
at least one task has done something. This may block. In the latter
case, the call will return immediately if there was no work to do.
The changes are useful when running existing programs under ISIS or
when working within an existing lightweight task package. They
permit arbitrary tasks to enter and exit ISIS at will and allow
you to avoid the isis_mainloop routine -- which was a bit of
a problem previously, when integrating existing code into ISIS.
Stack size limits used to be a concern and might have forced
you to call t_on_sys_stack, which works but was a bit painful.
In the new scheme, the old program runs as it always did, but
periodically invokes isis_accept_events(0/ISIS_BLOCK) to let
ISIS run for a while. The old isis_mainloop() can be thought
of as running isis_accept_events(ISIS_BLOCK) in an infinite loop.
o BYPASS communication facility gives huge speedup, supports
specialized user-provided transport protocols
This is an experimental feature (e.g. it probably is still buggy
in V1.2) and we don't compile it in by default yet. If you enable
it, cbcast (and fbcast), but not abcast, are transmitted directly
in the following cases: member to whole group (including "x" option),
member to clients (a new "c" option), and reply from a member to
a member or to a client. You can sometimes get the effect of a
fast abcast using a "cbcast token", but be aware that this might
not be ordered w.r.t. abcast sent via the normal abcast protocol.
We will be allowing users to define their own protocols for
multicast message transport, too. See the manual (appendix D)
for details.
o isis_enter_stacksize(enum, size): sets size of task stack on
a per-entry basis.
o Suntools users should call isis_suntools_init(port-no) instead
of isis_init(port-no) (SUN OS 4.0 and subsequent revisions)
o isis_input_sig: does a t_sig when input is available
o isis_signal_sig: does a t_sig when signal is received
o isis_chwait, isis_chwait_sig: does callback/signal when a child terminates
This lets you know when it is safe to call `wait'.
o "exit()" may not do what you expect!
Specifically, on SUN LWP the semantics of "exit" were changed (wrongly!)
by the LWP people to mean "terminate the current task". This is rarely
what the user intended, since it leaves the process running. So, ISIS
defines "exit" to be "_exit" under SUNOS. This, however, may fail to flush
output channels. You can undefine our define if you like.
There seems to be a related problem on APOLLO UNIX 10.1, but since
the APOLLO documentation says nothing about it, we think it is an
APOLLO bug.guy@bevsun.bev.lbl.gov (Aran Guy) (05/11/89)
In <27301@cornell.UUCP>
o In a particle physics experiment. We are talking to one
group that hopes to use ISIS to implement a distributed con-
trol program. It will operate data collection devices, farm
out the particle track calculations onto lightly loaded
workstations, collect the results, and adapt to failures
automatically by reconfiguring and shifting any interrupted
computation to an operational machine.
I am one small cog in a group that is modernizing the Bevalac
complex computerised control system. We are taking a mixed
Modcomp/Intel(Old ISIS!) system and slowly upgrading to a Sun
based distributed processing layout usine VME crates and
having dvDraw/dvTools as the operator interface.
I get to draw up the pretty screens.
The system will monitor and control upwards of a thousand analog
or digital devices spread out among two discrete but connected
heavy ion accelerator complexes, where up to four experiments
using different ions at different energies can be run
simultaneously.
If anyone can e-mail me any details of the above described
particle physics experiment, I'd appreciate it.
I'm neither a physicist nor a hacker, just someone slowly
moving up from the button-pushing stage.
Thanks
Aran Guy guy@bevsun.bev.lbl.gov
Disclamer: Lamer? I can stop that disc dead in it's tracks!
HILAC HILAC
HILAC WE SMASH ATOMS HILAC
HILAC HILACken@gvax.cs.cornell.edu (Ken Birman) (05/11/89)
In article <2602@helios.ee.lbl.gov> guy@bevsun.bev.lbl.gov (Aran Guy) asks: > > In <27301@cornell.UUCP> [Cornell describes some ISIS uses, including:] > > o In a particle physics experiment... > ... > If anyone can e-mail me any details of the above described >particle physics experiment, I'd appreciate it.... > You got us here. I believe we noted that we were "talking to" this group. They eventually decided that they would have to run under VMS. At this stage there is no VMS port for ISIS, and my understanding is that they went for a much less general solution oriented around a VAX cluster system without dynamic load sharing. (We would be happy to talk to your group about using ISIS for something along these lines, on the other hand! I think it would be a fairly straightforward problem, and the benefits could be substantial in terms of flexibility, modularity, etc. (Plus, I wouldn't have to edit the ISIS blurb to delete this particular example :-) Ken Birman