pierson@mist.encore.com (Dan L. Pierson) (04/27/89)
Are any of you using the Mul-T language? We know who we shipped it
to, but have no idea who may have gotten it off the net from MIT.
If you're a user, please mail me the email address of a contact person
and any comments you might have. The implementors would like some
feedback.
For those of you who have no idea what I'm talking about, the
following is extracted from the start of the Mul-T release notes:
Mul-T is a version of the T programming language allowing
multiprocessing in the style of Multilisp. Mul-T is based on the
Orbit optimizing compiler, and overcomes many of the performance
problems of previous Multilisp implementations.
Lightweight tasks are created in Mul-T using the future construct of
Multilisp. The expression (future form) returns a psuedo-first-class
object called a future, a promise to yield the value of form at some
future time. Futures may be passed as arguments and returned as
values; if the value of a future is required before it has been
determined, the task requiring the value will be suspended until the
value is available.
The terms ``task'' and ``future'' should be distinguished. A ``task''
is a thread of control performing a computation, while a ``future'' is
an object returned by the future construct, ultimately containing the
value computed by a task.
In addition, Mul-T introduces the concept of a group, a collection of
related tasks which can be started, stopped, resumed, and killed
independently of other groups of tasks.
Users familiar with T may find that the style of access to futures and
groups in Mul-T is different than access to T's other primitive data
types, which tend to be first-class objects completely manipulable by
the programmer. The only operation provided for futures is the
dereferencing touch, and groups are only manipulable from a top-level
command interpreter. There are two reasons for this. First, futures
are intended to support a declarative style of parallelism that is
higher-level than program-based task manipulation. Second, the
foremost goal of Mul-T is performance; providing more programmer
control of futures and groups requires unacceptable overhead. Future
versions of Mul-T may allow more explicit programmer control.
Users familiar with Multilisp should find that their programs run
overwhelmingly faster in Mul-T.
dan
In real life: Dan Pierson, Encore Computer Corporation, Research
UUCP: {talcott,linus,necis,decvax}!encore!pierson
Internet: pierson@encore.com