From: axb@cse.nd.edu (Arindam Banerji)
Newsgroups: comp.os.research
Subject: Re: A challenge
Date: 13 Apr 92 11:58:16 GMT
Article-I.D.: darkstar.32798
Organization: Distributed Computing Research Lab, Notre Dame
Originator: osr@ftp

The following is based upon the basic premise that an operating system
normally provides abstractions that represent a set of resources (
processes, processors, files, virtual memory, etc. ) and events generated by
these resources ( interrupts, signals etc. ). Any implementation of these
abstractions would ALSO have to provide resource controllers and event
managers. Another basic design approach that this note assumes is that even
though new abstractions may best be left to language designers, it is still
very important to restructure the existing abstractions to adapt them to
new hardware + network architectures as well as changing needs of
application builders.

1. Choice of Abstractions  ( as seen by the programmer)
   The discussion over asynchonous vs synchronous services is potentially
   endless - 'cos for many applications an asynchronous set of services are
   the perfectly natural building mechanism. Similiarly, a shared data model
   that requires synchronized accesses pefectly suits some applications.
   The application builder should have multiple kinds of resources to build
   distributed applications. It is possible to provide a synchronous and
   asynchronous service interfaces for many abstractions. Similiarly a
   single abstraction may be used for both message passing as well DSM based
   abstractions.
   Example : ARCADE's data unit abstractions can be MOVED ( or passed around
   as messages) or SHARED ( DSM sharing with some extensions). The service
   interface to this abstraction allows for both blocking and non-blocking
   use of the interface. It is upto the application builder to choose the
   appropriate model.
   There is absolutely no need to restrict the application builder's choices

2. Nature of Abstractions
   Most system and application software is written in high-level languages
   these days (except in DOS ofcourse). Applications are built around the
   constructs provided by these high-level languages - constructs such as
   procedure calls, shared data, objects etc. Why shoudn't the operating
   system directly provide support for higher-level mechanisms such as
   those found in high-level languages anyway - such as shared data,
   objects, etc. Low-level control over abstractions can be provided thru
   a hierarchical service call interface, which allows the programmer to
   only have to deal with as much complexity as they need. DSM abstractions
   for this reason need
   This approach provides the advantage that it does not restrict
   implementation strategies. The same abstraction may be implemented as a
   micro-kernel, macro-kernel or add-ins to existing operating systems.
   Wouldn't it be nice to have DSM abstraction in a micro-kernel like
   Mach interact equally with DSM additions to OS/2 and UNIX ? Well, the
   ARCADE data unit abstraction allows for just that.

3. Application specificity
   A single abstraction may be implemented in many ways - a particular
   implementation usually reflects a specific set of design choices. For
   many applications this specific set of design choices may be less than
   optimal. As an example, consider a system that provides only sequential
   coherency DSM. Many applications can live with less restrictive
   coherency schemes.
   An implementation of an abstraction should be able to handle the vagaries
   of different application requirements, as much as possible. In case of
   DSM, the implementation should be able to provide for both sequential
   and weak coherency. The question of how an implementation figures out
   which set of design choices are to be used is a a little trickier. This
   would actually depend upon the abstraction in question. IN certain cases,
   the implementation would deduce this information from accounting
   information that it maintains and in certain cases the application
   builder directly conveys this information to the operating system.

4. Process models
   Based upon the notion that an execution thread resource may be attached
   several resources such as data resources, a time slice resource etc. and
   each of these resources may be shared or singly-owned, a process model
   may be made general enough to include light-weight user level threads,
   kernel-level threads, named processes etc. The application builder may
   choose any particular incarnation of such a process model, depending
   upon the requirements of the application. There is no necessity to
   provide separate abstractions for threads ( user-level, kernel or
   whatever) and processes.


5. Data Models
   Any application whether it views its data as contained within objects or
   treats data as treated by regular procedural languages needs support
   for a basic data model. Point #1 argues that such a data-model which
   should not restrict the application builders model of computation, should
   be supported by the operating system.
   One particular way of viewing such a model is in the form of a digraph
   where each node is a data item and edges represent references. ARCADE
   implements such a data model, where each node holds data (associated
   with simple type info. as metadata) and references are thru a distributed
   abstraction called Data Unit links, which subsumes the implementation of
   global pointers.
   It is thus necessary to provide not only for shared data and movable
   data ( message-passing) but also for a reference mechanism that does not
   necessarily depend upon shared address spaces or homogenous
   architectures.


 Arindam Banerji
 ( axb@irishvm.pcl.nd.edu )
 ( axb@cse.nd.edu )
 (219)-239-5273