home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.20 / text0044.txt < prev    next >
Encoding:
Internet Message Format  |  1990-08-02  |  6.0 KB
  1. From:  <jsh@usenix.org>
  2.  
  3.  
  4.            An Update on UNIX*-Related Standards Activities
  5.  
  6.                               June, 1990
  7.  
  8.                  USENIX Standards Watchdog Committee
  9.  
  10.                    Jeffrey S. Haemer, Report Editor
  11.  
  12. IEEE 1003.14: Multiprocessing
  13.  
  14. Bill Cox <bill@attunix.att.com> reports on the April 23-27 meeting in
  15. Salt Lake City, UT: The POSIX Multiprocessing Study Group had its
  16. first official meeting as P1003.14 in Utah, where the SEC approved its
  17. Project Authorization Request (PAR) for a Multiprocessing Execution
  18. Environment Profile.  Multiprocessing systems have become cost-
  19. effective means for providing computing power, but with the advantages
  20. have some specific concerns that need to be addressed at the interface
  21. level.  The goal of this work is to try to make POSIX safe for
  22. multiprocessing; a secondary goal is to try to make POSIX hospitable
  23. for multiprocessing.  POSIX working groups do not necessarily share
  24. the concerns of the implementors and users of multiprocessing systems.
  25.  
  26. Bob Knighten (Encore) is the Chair, Bill Cox (AT&T UNIX Software
  27. Operation) is Secretary, and Dave Plauger (Alliant) is the Technical
  28. Editor.  Officers must have a commitment of support from their
  29. employers, to ensure that they can attend working group meetings and
  30. devote necessary time to the purposes of the working group.  16 people
  31. attended the group meetings.
  32.  
  33. People interested in .4A (threads) have tended to be interested in .14
  34. and vice versa.  Many .14 members that have been meeting with
  35. P1003.4/.4A see substantial problems with pthreads in a multiprocessor
  36. environment, and I know at least eight people working on .4A that want
  37. to come work in .14.
  38.  
  39. The working group designated one official liaison to .4A, who was
  40. joined by two other tentative volunteers.  We will also establish
  41. liaisons with .1, .6, .7, .8, .10, and .12.
  42.  
  43. During the week, we spent time in three areas.
  44.  
  45.   1.  We clarified the group's work items, and started work on the
  46.       most important, the Application Environment Profile.  (An AEP
  47.       may specify relevant portions of other POSIX working groups'
  48.       work, make choices where options are permitted, and specify
  49.       behavior that a [draft] standard may have left undefined or
  50.       unspecified.)
  51.  
  52. __________
  53.  
  54.   * UNIX is a registered trademark of AT&T in the U.S. and other
  55.     countries.
  56.  
  57. June, 1990 Standards Update              IEEE 1003.14: Multiprocessing
  58.  
  59.  
  60.                 - 2 -
  61.  
  62.   2.  We discussed current conventional wisdom on multiprocessing.
  63.       The discussions centered around presentations by BBN, Cray,
  64.       Encore, AT&T USO, and Alliant on lessons they've learned.
  65.  
  66.   3.  We created two small groups.
  67.  
  68.       The first began work on high-level requirements placed on
  69.       pthreads by multiprocessing.  Attendees included Rick Greer
  70.       (Interactive), Mary Weeks (Sun), and Bill Cox (AT&T USO).
  71.  
  72.       Here are some requirements we feel strongly about:
  73.  
  74.          + A library implementation of ``user-level threads'' is
  75.            vitally important.  User-level threads often must be
  76.            multiplexed onto kernel-supported
  77.            objects/processes/threads, largely for performance reasons.
  78.            These kernel-supported objects, etc, are sometimes called
  79.            ``virtual processors,'' because they support an abstraction
  80.            closer to that of a physical processor, with
  81.            interrupts/signals, and a significant amount of state.
  82.  
  83.          + The formal memory model of P1003.4/D9 section 13.1 must
  84.            apply to .4A.  This model defines the semantics of memory
  85.            interaction that should be preserved in a multithreaded or
  86.            multiprocessing environment.
  87.  
  88.          + Global threads scheduling makes little sense in a
  89.            multiprocessor, though such scheduling could be useful as a
  90.            hint (Like C's register declarations if you don't have
  91.            enough registers.) Global policy is difficult to implement
  92.            in a multiplexed thread environment.
  93.  
  94.          + use of attribute structures for mutual exclusion variables
  95.            (in particular, for scheduling hints)
  96.  
  97.          + Locks shouldn't be opaque, and programmers should be able
  98.            to statically initialize them.  The latter is important so
  99.            that locks can be part of data structures, and not require
  100.            time-consuming dynamic allocation and initialization.
  101.  
  102.          + There must be only one set of libraries.  There are
  103.            performance reasons to have single-threaded libraries,
  104.            i.e., libraries that are not thread-aware, for a
  105.            uniprocessor or single-threaded applications.  The group
  106.            believes that the cost of maintaining such libraries is
  107.            sufficiently high that a non-reentrant library or set of
  108.            libraries should not be required.
  109.  
  110. June, 1990 Standards Update              IEEE 1003.14: Multiprocessing
  111.  
  112.  
  113.                 - 3 -
  114.  
  115.       The other group began work on the AEP itself.
  116.  
  117.       Members of this small group, and their responsibilities,
  118.       included
  119.  
  120.          + Dave Plauger (Alliant) - skeleton for the document,
  121.  
  122.          + Frank Lawlor (IBM) - checkpoint restart, review, and
  123.            liaison with .10 and .7,
  124.  
  125.          + James Gibson (BBN) - review and liason with .2,
  126.  
  127.          + Bob Knighten (Encore) - review and liason with .4, and
  128.  
  129.          + Tom Weaver (IBM) - review and liason with .1 and .6.
  130.  
  131.       This group identified several areas of concern:
  132.  
  133.          + microtasking models
  134.  
  135.          + checkpoint, snapshots, and core dump format/synchronization
  136.  
  137.          + a general programming model
  138.  
  139.          + dividing the ``reading list'' (other P1003 standards and
  140.            drafts)
  141.  
  142.          + determining focus (are we dealing with portability for
  143.            application writers, users, and/or administrators?)
  144.  
  145.          + standardizing system services
  146.  
  147.       A sketch of the planned document includes:
  148.  
  149.          + reference to TIMS
  150.  
  151.          + multithreaded applications (.4A)
  152.  
  153.          + HLL parallel applications (PCF FORTRAN, parallel C)
  154.  
  155.          + IPC
  156.  
  157. June, 1990 Standards Update              IEEE 1003.14: Multiprocessing
  158.  
  159. Volume-Number: Volume 20, Number 44
  160.  
  161.