home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / v20 / repdir / 1003.4 < prev    next >
Internet Message Format  |  1990-08-02  |  4KB
  1. From jsq@longway.tic.com  Sat May 19 15:44:38 1990
  2. Received: from cs.utexas.edu by uunet.uu.net (5.61/1.14) with SMTP 
  3.     id AA28156; Sat, 19 May 90 15:44:38 -0400
  4. Posted-Date: 19 May 90 19:34:52 GMT
  5. Received: by cs.utexas.edu (5.61/1.62)
  6.     id AA06978; Sat, 19 May 90 14:44:34 -0500
  7. Received: by longway.tic.com (4.22/4.16)
  8.     id AA11134; Sat, 19 May 90 14:35:24 cdt
  9. From: <usenix.org!jsh@longway.tic.com>
  10. Newsgroups: comp.std.unix
  11. Subject: Standards Update, IEEE 1003.4: Real-time Extensions
  12. Message-Id: <695@longway.TIC.COM>
  13. Sender: std-unix@longway.tic.com
  14. Reply-To: std-unix@uunet.uu.net
  15. Date: 19 May 90 19:34:52 GMT
  16. Apparently-To: std-unix-archive@uunet.uu.net
  17.  
  18. From: <jsh@usenix.org>
  19.  
  20.  
  21.            An Update on UNIX*-Related Standards Activities
  22.  
  23.                                May 1990
  24.  
  25.                  USENIX Standards Watchdog Committee
  26.  
  27.                    Jeffrey S. Haemer, Report Editor
  28.  
  29. IEEE 1003.4: Real-time Extensions
  30.  
  31. Rick Greer <rick@ism.isc.com> reports on the April 23-27 meeting in
  32. Salt Lake City, UT:
  33.  
  34. 1003.4
  35.  
  36. The .4 ballots went out on schedule, and most came back on schedule as
  37. well.  We (barely) got the required 75% response, of which 43%
  38. approved of the draft as it stood.  The small-group leaders are
  39. currently working to resolve the objections and will report back at
  40. Danvers, in July.
  41.  
  42. 1003.4a
  43.  
  44. Most of the work at Snowbird centered around threads (.4a).  Two
  45. alternatives to the pthreads proposal were presented at the meeting:
  46. ``strands'', from John Zolnowsky of Sun, defined a minimal set of
  47. interfaces for multi-threaded applications; ``VP'', from Paul Borman
  48. of Cray, added a ``virtual processor'' layer to the pthreads
  49. specification, which made some multiprocessor (MP) features visible to
  50. applications.
  51.  
  52. The primary MP hardware feature that Paul's VP proposal makes visible
  53. to the pthreads environment is the ability to write your own spin
  54. loops and expect them to work.  One could, for example, have one
  55. thread continuously reading an in-core data base while another thread
  56. updates it.  On an MP system, it might be more efficient to code this
  57. without using a mutex, although doing so on a uni-processor with a
  58. co-routine threads package is an absolute disaster.  The new
  59. multiprocessor group, 1003.16, is looking into this and similar
  60. problems, and will probably suggest that .4a include some sort of
  61. system-wide attribute structure that one can check when writing
  62. programs that depend heavily on concurrent execution of threads.
  63.  
  64. After a week's discussion (often a euphemism for argument), we settled
  65. into a compromise position not that far from where we started --
  66.  pthreads.  All this work without much net change was frustrating, but
  67.  
  68. __________
  69.  
  70.   * UNIX is a registered trademark of AT&T in the U.S. and other
  71.     countries.
  72.  
  73. May 1990 Standards Update            IEEE 1003.4: Real-time Extensions
  74.  
  75.  
  76.                                 - 2 -
  77.  
  78. probably unavoidable.  Until fairly recently most of the committee was
  79. busy getting the .4 draft ready for balloting.  Lacking enough time to
  80. have studied threads carefully, members were unwilling to accept the
  81. small group's conclusions before investigating some alternatives for
  82. themselves.  Still, some progress was made.  The most important was a
  83. more comprehensive definition of signal behavior in multi-threaded
  84. programs.
  85.  
  86. 1003.14
  87.  
  88. On the last day, a first attempt at a real-time application
  89. environment profile (AEP) was presented.  This PAR will be an
  90. excellent, practical test of AEPs.  Real-time applications are likely
  91. to vary wildly in the subsets of .4's rich features that they require.
  92. Some worry that the real-time AEP will force embedded systems that
  93. need only one or two .4 features to incorporate others just to adhere
  94. to the standard.  The problem this poses is not just storage space
  95. wasted by unused code, but the expense of verifying that this extra
  96. code will never get in the way of the application.  The group will be
  97. wrestling with these and similar problems in the months to come.
  98.  
  99. May 1990 Standards Update            IEEE 1003.4: Real-time Extensions
  100.  
  101.  
  102. Volume-Number: Volume 20, Number 5
  103.  
  104.