[mod.compilers] 2 More Concurrent Programming Languages

johnl@ima.UUCP (Compilers mailing list) (11/04/86)

    There are two high-level languages for concurrent programming at the
University of Toronto.  The first is Concurrent Euclid, which has been in use
since 1981, and the second is Turing Plus, which is currently under
development.

    Concurrent Euclid (ConEuc) inherits its constructs from the Euclid 
programming language, designed in 1975 for developing verifiable systems
software.  Thus ConEuc is designed with verification in mind and these same
constructs have been shown to enhance readability and understandability.
ConEuc provides many restrictions on programs such as strong type checking
and anti-aliasing.
    ConEuc implements concurrency using statically declared processes and 
monitors.  Each process declared represents a separate unit of activity that
can act concurrently with other processes.  This is combined with monitors as
defined by C.A.R. Hoare.  These are similar to modules but they guarantee
that only one process at a time is active inside them.  When a process tries 
to enter a monitor's scope that already has an active process, the entering
process is blocked.  Within a monitor, processes can wait on condition queues
(which may be specified with priority ordering).  A waiting process is 
activated when another process within the same monitor signals the condition.
    ConEuc was designed for high-performance, highly reliable, portable systems
software.  A UNIX look-alike operating system (compatible at the file-system
level) has been implemented in ConEuc and various implementations have been
enhanced for distributed and master/slave multiprocessor systems.  ConEuc is
available on the IBM CMS, DEC VAX VMS, DEC VAX 4.2BSD, SUN UNIX, and IBM PC's
(and compatibles).

    Turing Plus (T+) is currently under development.  It is a general purpose
language particularly suited to systems programming.  T+ is a compatible
extension of the Turing programming language developed at the University of
Toronto in 1983 and used since then as the introductory programming language.
    Turing and T+ are defined with a formal axiomatic and operational
semantics.  T+ concurrency is similar to ConEuc's with the addition of a
"fork" statement to activate a copy of a process.  T+ uses monitors with the
same meaning as ConEuc's with the addition of a device monitor which has its
exclusive access enforced by a machine dependent trick such as executing it
at the hardware priority given.  The wait on condition and signal to wake
condition is extended to allow deferred conditions as opposed to only allowing
immediate conditions (where the signalling process immediately waits while the
signalled process becomes active).  A timeout option is also allowed that
specifies the interval after which a waiting process is automatically
signalled.  Process priority can be read and set as well.

    For more information, you can write to the
	CSRI Distribution Manager
	Computer Systems Research Institute
	University of Toronto
	10 King's College Rd. SF2002
	Toronto, Ontario  M5S 1A4

Available information includes:
	CSRI-133, SPECIFICATION OF CONCURRENT EUCLID, J.R. Cordy & R.C. Holt
	CSRI-152, STRUCTURE OF A PORTABLE OPERATING SYSTEM, M. Mendell
	CSRI-153, THE TURING LANGUAGE REPORT, R.C. Holt & J.R. Cordy
	CSRI-176, THE TUNIS REPORT: DESIGN OF A UNIX-COMPATIBLE OPERATING
		    SYSTEM, P. Ewens, R. Holt, M. Funkenhauser & D. Blythe
	CSRI-182, THE FORMAL SEMANTICS OF TURING PROGRAMS,
		    R.C. Holt & P. A. Matthews
	CSRI-186, FEATURES OF THE TURING LANGUAGE, R.C. Holt
	CSRI-187, DESIGN GOALS FOR THE TURING PROGRAMMING LANGUAGE, R.C. Holt
	THE TURING PLUS REPORT, R.C. Holt & J.R. Cordy
	SOFTWARE EXCELLENCE - List of relevant research products and
		    distribution prices
-- 
Stephen Perelgut    Computer Systems Research Institute, University of Toronto
Licence is granted to retransmit this message so long as the body, Subject,
addressee's and sender are not altered in any way.  This message is not to
be transmitted to anyone other than the original adressee's.

-- 
Send compilers mail to ima!compilers or, in a pinch to Levine@YALE.EDU
Plausible paths are { ihnp4 | decvax | cbosgd | harvard | yale | bbncca}!ima

Please send responses to the originator of the message -- I cannot forward
mail accidentally sent back to compilers.  Meta-mail to ima!compilers-request