home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.18 / text0023.txt < prev    next >
Encoding:
Internet Message Format  |  1990-03-18  |  4.9 KB
  1. From: <jsh@usenix.org>
  2.  
  3.  
  4.             An Update on UNIX* and C Standards Activities
  5.  
  6.                              January 1990
  7.  
  8.                  USENIX Standards Watchdog Committee
  9.  
  10.                    Jeffrey S. Haemer, Report Editor
  11.  
  12. IEEE 1003.4: Real-time Extensions Update
  13.  
  14. Rick Greer <rick@ism.isc.com> reports on the January 8-12, 1990
  15. meeting in New Orleans, LA:
  16.  
  17. 1003.4 goes to ballot
  18.  
  19. The big news in 1003.4 is that some of it is ready for balloting.  My
  20. copy of the dot-4 ballot was waiting for me when I got back from New
  21. Orleans.  The current draft is a 330-page, eclectic collection of
  22. real-time features.  Some (e.g., asynchronous event notification)
  23. address significant deficiencies in the dot-1 base, but others (e.g.,
  24. IPC message passing) seem to be of limited value.  It remains to be
  25. seen whether the limited applicability of some of the proposed
  26. features is enough to shoot down the entire ballot.
  27.  
  28. One area that may cause trouble is the shared-memory model in the
  29. Language-Specific Requirements section.  While this language-
  30. independent model addresses a real need--serialization of reads and
  31. writes in the presence of simultaneous updates to a common store--it
  32. does so rather formally; people uncomfortable with formal,
  33. mathematical models may be put off by it.  The fact remains, however,
  34. that both dot 1 and the ANSI C standard failed to address this
  35. problem, which is critically important in shared-memory multiprocessor
  36. architectures.
  37.  
  38. Threads
  39.  
  40. The threads proposal is only an appendix in the current draft, and
  41. won't be subject to formal ballot.  Though there were too many loose
  42. ends in the threads proposal to send it to ballot in this round, most
  43. of them were tied up in New Orleans.  We should have a ballotable
  44. draft ready after the April meeting.
  45.  
  46. Meanwhile, the active membership in the threads "small group" is
  47. changing.  Representation from the Ada community has grown from two to
  48. six; almost a quarter of the active membership is now familiar with
  49.  
  50. __________
  51.  
  52.   * UNIX is a registered trademark of AT&T in the U.S. and other
  53.     countries.
  54.  
  55. January 1990 Standards Update        IEEE 1003.4: Real-time Extensions
  56.  
  57.  
  58.                                 - 2 -
  59.  
  60. Ada and its multitasking model.  Most threads people, including me,
  61. are also becoming active in the new multiprocessor study group.
  62.  
  63. Discussion within the multiprocessor group promises to be quite
  64. lively, since the threads group's more contentious issues (e.g.,
  65. signals) were skirted by defining high-level interfaces, leaving
  66. details of low-level behavior unspecified.  The multiprocessor group,
  67. on the other hand, must deal with the low-level behavior of
  68. multiprocessor configurations, and many of the old arguments have
  69. already re-surfaced (e.g., should signal state be maintained per-
  70. process or per-thread?).  Using high-level interface specifications to
  71. dodge low-level implementation issues does have its problems, though.
  72. People unaware of more subtle implementation issues tend to view new,
  73. high-level interfaces as unnecessary complications.  It's difficult to
  74. convince them that, even if consensus could be reached regarding the
  75. behavior of primitive functions, we would still need high-level
  76. interfaces (or rigid coding disciplines) to guarantee that
  77. independently developed routines use primitives consistently when
  78. addressing common problems.  The real sticker here has been how to
  79. asynchronously terminate a thread and cause it to execute cleanup
  80. code.  Everyone agrees that this is necessary.  Some members,
  81. particularly those from AT&T/USO, feel that the best way to provide
  82. this facility is by minor enhancements to traditional UNIX signals,
  83. but most of the group feels that the best way to deal with notorious
  84. signal races in a uniform, language-independent manner, is to adopt a
  85. high-level interface, modeled after one used by DEC/SRC.
  86.  
  87. 1003.4 turns into .4, .4A, .4B, .4C, and .14
  88.  
  89. There are three other major, on-going efforts in dot 4: language-
  90. independent specification of the real-time extensions, identification
  91. and specification of other, important, non-threads, real-time
  92. extensions that didn't make it into the current ballot, and
  93. specification of a real-time application profile.  The first is
  94. farthest along, but none is anywhere near completion.  Recognizing
  95. that these efforts were separate from the current proposal, and from
  96. one another, the working group submitted four new Program Action
  97. Requests (PARs).  The Sponsor Executive Committee (SEC) approved all
  98. four, and decided that the application-profile effort was so distinct
  99. that it needed a new number.  The working group's five PARs are now
  100.  
  101.               the current ballot                1003.4
  102.               threads                           1003.4A
  103.               language independence             1003.4B
  104.               further real-time extensions      1003.4C
  105.               real-time application profile     1003.14
  106.  
  107. January 1990 Standards Update        IEEE 1003.4: Real-time Extensions
  108.  
  109.  
  110. Volume-Number: Volume 18, Number 24
  111.  
  112.