home *** CD-ROM | disk | FTP | other *** search
/ Usenet 1994 January / usenetsourcesnewsgroupsinfomagicjanuary1994.iso / sources / std_unix / volume.27 / text0066.txt < prev    next >
Encoding:
Text File  |  1992-05-20  |  40.6 KB  |  1,142 lines

  1. Submitted-by: knighten@intel.com (Robert L. Knighten)
  2.  
  3. Draft 12 of the P1003.4 (Realtime Extension) draft standard is in its fourth
  4. ballot (and third recirculation.)  This latest ballot is due at the IEEE
  5. Standards Office on April 10.  
  6.  
  7. Last work the following group met and drafted a Common Reference Ballot which
  8. we hope will be considered by other members of the ballot group before they
  9. submit their own ballots.  Our CRB is included at the end of this message.
  10.  
  11. The CRB will be submitted as the first 40 items in the ballot of
  12. Robert L. Knighten of Intel Supercomputer Systems Division.
  13.  
  14. Nawaf Bitar             Kubota-Pacific
  15. David Black             Open Software Foundation
  16. Bob Conti               Digital Equipment Corporation
  17. Bill Cox                Unix Systems Laboratories
  18. Michael Jones           Carneige-Mellon University
  19. Steve Kleiman           SunSoft
  20. Bob Knighten            Intel Supercomputer Systems Division
  21. Jim Pitcairn-Hill       Open Software Foundation
  22. Dave Plauger            Hewlett-Packard
  23. Paul Rabin              Open Software Foundation
  24.  
  25. This CRB is also available in various forms (ASCII, postscript, troff) by
  26. anonymous ftp from export.ssd.intel.com in the directory /pub/tmp/CRB.
  27.  
  28. This same group has also done a common reference ballot for the P1003.4a
  29. (Pthreads) draft and that will be available on April 13.
  30. ==============================================================================
  31.  
  32. --------------------------------------------------------------------------
  33. @ all o 1
  34. 1: Section all page all line(s) all
  35.  
  36. OBJECTION:
  37.  
  38.  The use of errno is a mistake with new functions. Existing POSIX.1 functions
  39.  and their close relatives (e.g. fdatasynch()) should maintain their overall
  40.  structure, as should those tied to existing practice (e.g.  mmap, memlock, et
  41.  al.). The use of errno as a global error indicator in multithreaded
  42.  environments introduces new difficulties.
  43.  
  44. ACTION:
  45.  
  46.  New functions (e.g. aio_read, sem_post) should not set a global errno, but
  47.  instead return an error indication as the function return value. We do not
  48.  provide synopses for all such functions, but will on request from the
  49.  technical reviewers.
  50.  
  51.  Change all new functions such as the aio functions and sem_ functions to
  52.  return an error indication on failure.
  53.  
  54.  
  55. --------------------------------------------------------------------------
  56. @ all o 2
  57. 2: Section all page all line(s)
  58.  
  59. OBJECTION:
  60.  
  61.  We join in UO193.D11. The performance metrics are not consistent, and are not
  62.  appropriate to this standard. Improving something that does not belong does
  63.  not solve the problem. Deleting them will. The problem is not quality but
  64.  timeliness and applicability.
  65.  
  66. ACTION:
  67.  
  68.  Delete all performance metrics from D12 and forward the text to a
  69.  benchmarking standards group.
  70.  
  71.  
  72. --------------------------------------------------------------------------
  73. @ Introduction c 3
  74. 3: Section Introduction page viii line(s) 17-18
  75.  
  76. COMMENT:
  77.  
  78.  This makes the same sweeping generalization as in lines 16-17 page 2, and
  79.  should also be amended and clarified.
  80.  
  81. --------------------------------------------------------------------------
  82. @ 1.1 o 4
  83. 4: Section 1.1 page 1 line(s) 5
  84.  
  85. OBJECTION:
  86.  
  87.  We join with unresolved objection UO.3.D11. Performance metrics are not the
  88.  appropriate province of a source interface standard. There are groups that
  89.  define benchmarks; the information requested in the performance metrics
  90.  sections (sections 3.9.10, 3.10.5, 6.6.3, 6.7.9, 17.3, 19.2, 20.3, 20.4.6,
  91.  21.4, 21.5.5, 22.3, 23.3, 23.4.6, 24.4, and 24.5.8) should be defined by
  92.  those groups, and not TCOS-sponsored POSIX working groups.
  93.  
  94. ACTION:
  95.  
  96.  Delete line 5. In addition, delete all performance metrics as out of scope.
  97.  
  98.  
  99. --------------------------------------------------------------------------
  100. @ 1.1 o 5
  101. 5: Section 1.1 page 2 line(s) 12-44
  102.  
  103. OBJECTION:
  104.  
  105.  We have objected previously to the extremely broad definition of "realtime,"
  106.  and we continue to object vigorously. As part of this objection we point out
  107.  that using names such as "{_POSIX_MAPPED_FILES}" and "{_POSIX_SEMAPHORES}"
  108.  contributes to the vague broad definition of "realtime" being used.
  109.  
  110.  It is encouraging that application to multiprocessors and networking are
  111.  specifically excluded from scope.  However, the extremely broad nature of
  112.  lines 22-23 renders the limiting to a "...set required to make this standard
  113.  minimally useful to realtime applications on single processor systems" (lines
  114.  12-13) a too-subtle attempt at humor.
  115.  
  116.  The reviewer's response to unresolved objections (e.g. to W. T. Cox D11
  117.  objection 7, marked "nonresponsive") is itself not a response but an excuse.
  118.  In part, the reviewer said "...the scope is determined by the approved PAR
  119.  and further refined in the informative text of the draft. The items
  120.  [asynchronous I/O and realtime files, among others] ... are well within
  121.  scope."
  122.  
  123.  We would appreciate the specification of any interface that is not within the
  124.  scope as written in D12 and previous drafts. The only justification that
  125.  appears to serve to delete functionality that is not considered "realtime" is
  126.  an outcry from the balloting group. POSIX.4 appears to take the mechanistic
  127.  (and self- referential) approach that "realtime is anything that's in
  128.  POSIX.4." This absence of anything outside your scope makes it difficult to
  129.  convince the technical reviewers that any particular 'nice interface' is
  130.  inappropriate -- you may only be able to convince them that the time is not
  131.  opportune to slip it past a balloting group.
  132.  
  133.  Moreover, objections to the broad nature of the scope have been called
  134.  "nonresponsive," and not circulated with other rejected comments to the
  135.  balloting group. What is more responsive to a call to validate a standard
  136.  with broad support than questions about the purpose and scope?
  137.  
  138. ACTION:
  139.  
  140.  The scope must be narrowed. One modification that would satisfy this
  141.  objection is to delete line 5 and replace lines 18-26: 
  142.  
  143.  The key elements defining scope are
  144.  
  145.  (a) defining a sufficient set of functionality to cover a significant part of
  146.  the realtime application domain, and
  147.  
  148.  (b) ensuring that the simultaneous support of the realtime extensions do not
  149.  impose undue burdens upon implementations that attempt to simultaneously
  150.  support both realtime extensions, POSIX.1 base functionality, and other
  151.  extensions currently being developed to POSIX.1.
  152.  
  153.  Specifically within the scope is to define interfaces which do not preclude
  154.  high performance implementations on traditional uniprocessor realtime
  155.  systems, but also to extend while focusing on traditional realtime systems
  156.  and needs such as timers, shared memory, scheduling, and interprocess
  157.  communication.
  158.  
  159.  The establishment of performance metrics are specifically out of scope; text
  160.  for proposed metrics are included in the rationale for each section, and will
  161.  be forwarded to other bodies for standardization.
  162.  
  163.  The establishment of benchmarks and performance enhancements for file systems
  164.  is also specifically out of scope.
  165.  
  166.  The signal mechanisms of POSIX.1 and existing implementations are already
  167.  extremely complex.  Adding an additional layer of complexity would not ensure
  168.  that high performance implementations and applications can be built using
  169.  such signal extensions. Accordingly, extensions to the POSIX.1 signals
  170.  mechanism are specifically out of scope.
  171.  
  172.  Wherever possible, the requirements of other application enrironments are
  173.  included in the interface definition.
  174.  
  175.  It is beyond the scope of these interfaces to support networking or
  176.  multiprocessor functionality.  (Rationale note: With this limitation on the
  177.  uniprocessor scheduling interfaces, all of the remaining functionality is
  178.  appropriate for closely-coupled multiprocessor systems.)
  179.  
  180.  
  181. --------------------------------------------------------------------------
  182. @ 2.2 o 6
  183. 6: Section 2.2 page 6 line(s) 24-25
  184.  
  185. OBJECTION:
  186.  
  187.  Direct I/O is not defined in a meaningful way. Moreover, direct I/O is only
  188.  discussed in the rationale to Chapter 24, so the definition does not belong
  189.  in normative text.
  190.  
  191. ACTION:
  192.  
  193.  Delete Lines 24-25.
  194.  
  195.  
  196. --------------------------------------------------------------------------
  197. @ 2.2 o 7
  198. 7: Section 2.2 page 10 line(s) 178-179
  199.  
  200. OBJECTION:
  201.  
  202.  Direct I/O is not defined in a meaningful way. Moreover, direct I/O is only
  203.  (according to the index) discussed in the rationale to Chapter 24, so the
  204.  definition does not belong here.
  205.  
  206. ACTION:
  207.  
  208.  Delete Lines 178-179.
  209.  
  210.  
  211. --------------------------------------------------------------------------
  212. @ 3.3 o 8
  213. 8: Section 3.3 page 23-24 line(s) 154-166
  214.  
  215. OBJECTION:
  216.  
  217.  SI_TIMER and SI_ASYNCIO and SI_MESGQ require either (1) a kernelized
  218.  implementation or (2) the ability for a user-level implementation to "fake" a
  219.  signal source. The existence of these SI_ values is in conflict with the
  220.  rationale and text for asynch I/O and other functions which say that
  221.  threads-based implementations should not be precluded.
  222.  
  223.  Sigqueue would have to similarly be a kernel implementation or have a back
  224.  door.
  225.  
  226.  Similarly, the timer mechanism would have to have a back door way to fake the
  227.  SI_TIMER codes. This has been a system-supplied value that cannot be spoofed
  228.  in the existing practice; a shift to signal-sender- settable values would be
  229.  a breach of existing practice and expectations.
  230.  
  231. ACTION:
  232.  
  233.  Delete this entire section; in the alternative, delete lines 157-162 and
  234.  (editorially) all references to the deleted text.
  235.  
  236.  
  237. --------------------------------------------------------------------------
  238. @ 3.3 o 9
  239. 9: Section 3.3 page 23 line(s) 159-160
  240.  
  241. OBJECTION:
  242.  
  243.  Forcing the signal code to return SI_ASYNCIO substantially complicates
  244.  implementations that implement asynchronous I/O by using threads. It forces
  245.  the implementation to modify the signal catching mechanism to cause a special
  246.  code to generated. Moreover, this requirement prevents an implementation
  247.  using threads.
  248.  
  249. ACTION:
  250.  
  251.  Delete lines 157-158
  252.  
  253.  
  254. --------------------------------------------------------------------------
  255. @ 3.3 o 10
  256. 10: Section 3.3 page 21-38 line(s) all
  257.  
  258. OBJECTION:
  259.  
  260.  The use of signals for notification of events of interest is a
  261.  low-performance technique. We have made objections whose action, if accepted,
  262.  will eliminate the need for signal notification of events of interest
  263.  including timer firing, asynchronous I/O completion, and IPC message
  264.  notification.
  265.  
  266.  The general idea is to pass or use a pointer to a function taking the
  267.  appropriate type as a parameter. There are two additional modifications
  268.  needed to support this improvement.
  269.  
  270. ACTION:
  271.  
  272.  On p20 line 41, delete the word "signal." (Notifications in exec'd process
  273.  are impossible.)
  274.  
  275.  On p21 l64 delete the word "signal."
  276.  
  277.  Delete section 3.3.
  278.  
  279.  
  280. --------------------------------------------------------------------------
  281. @ 5.4.5 o 11
  282. 11: Section 5.4.5 page 82 line(s) 416-482
  283.  
  284. OBJECTION:
  285.  
  286.  We join in UO38.D11 and UO47.D11. The shm_open() and shm_unlink() interfaces
  287.  serve no useful function and introduce needless confusion in code that will
  288.  use different functions for effectively the same purpose.
  289.  
  290. ACTION:
  291.  
  292.  Delete shm_open() and shm_unlink().
  293.  
  294.  
  295. --------------------------------------------------------------------------
  296. @ 6 o 12
  297. 12: Section 6 page all line(s) all
  298.  
  299. OBJECTION:
  300.  
  301.  These operations are trivially and more efficiently performed by using
  302.  threads.
  303.  
  304. ACTION:
  305.  
  306.  Delete this chapter.
  307.  
  308.  
  309. --------------------------------------------------------------------------
  310. @ 6.7 o 13
  311. 13: Section 6.7 page 59-77 line(s) 458-1118
  312.  
  313. OBJECTION:
  314.  
  315.  This section on asynchronous I/O has improved from previous drafts, but still
  316.  has a number of major problems:
  317.  
  318.  Notification is far too complex. The alternative of using OPTIONAL realtime
  319.  signals seems peculiar, and a burden on the programmer.
  320.  
  321.  The focus needs to be on creating interfaces that are implementable using the
  322.  synchronous I/O of threads.
  323.  
  324.  The reviewer's response to UO148.D11 is interesting, as he says that the
  325.  current chapter is not existing practice. This reinforces other unresolved
  326.  objections that state that the contents of this Section do not reflect
  327.  existing practice.
  328.  
  329. ACTION:
  330.  
  331.  Delete this Section.
  332.  
  333.  
  334. --------------------------------------------------------------------------
  335. @ 6.7 o 14
  336. 14: Section 6.7 page 59-77 line(s) 458-1118
  337.  
  338. OBJECTION:
  339.  
  340.  The response to UO148.D11 is not clear; the full text of the objection was
  341.  not presented. Since this text provided an alternative to the Section, UO148
  342.  was responsive, but the balloting group can neither evaluate text it has not
  343.  seen nor appreciate references to text not supplied in the unresolved
  344.  objections list.
  345.  
  346. ACTION:
  347.  
  348.  Include the text of unresolved objections per IEEE Standards Board procedures
  349.  and IEEE rules. Deliver the full text of UO148.D11 to the balloting group so
  350.  that references to that text in other unresolved objections make sense.
  351.  
  352.  
  353. --------------------------------------------------------------------------
  354. @ 6.7 o 15
  355. 15: Section 6.7 page 59-77 line(s) 458-1118
  356.  
  357. OBJECTION:
  358.  
  359.  In the event that our previous objection or others calling for deletion of
  360.  this section are not accepted, we make the following objection to the
  361.  notification mechanism. The action also addresses the problems stated in
  362.  unresolved objections numbers 149, 150, 152, 154, 156, and 157.
  363.  
  364.  The use of optional realtime signals is a burden, as a portable application
  365.  cannot know how much data can be passed, and a specific signal handling
  366.  routine must be scheduled after an expensive signal is sent.
  367.  
  368.  This is not consistent with "not precluding high-performance implementations"
  369.  as stated on page 2 lines 22-23. Signals by their very nature are low in
  370.  performance, and so-called "realtime signals" do not correct the situation.
  371.  In addition, the atomic update problem cited in, for example, UO.154.D11 and
  372.  the reviewer's response, is addressed.
  373.  
  374. ACTION:
  375.  
  376.  A simpler solution, provided in unresolved objection UO148.D11 but
  377.  accidentally deleted by the Unresolved Objections Editor, is to provide a
  378.  function to be called when the I/O operation is completed.  This is an
  379.  element of struct aiocb, and aio_errno and aio_result can be added to struct
  380.  aiocb and the functions aio_error and aio_return can be deleted.
  381.  
  382.  The new element, aio_notifunction (the name isn't very important, but the
  383.  concept is), is a pointer to a function that takes a pointer to struct aiocb
  384.  as its argument. When the asynchronous I/O operation completes, the function
  385.  referred to by aio_notifunction is called with a pointer to the completed
  386.  aiocb as its parameter. The notification function must be coded as if it has
  387.  no context: the effect of specifying a function that does process control,
  388.  longjmp, or thread control calls that assume a particular environment is
  389.  undefined.
  390.  
  391.  The rationale should state that the action of calling the notification
  392.  function is the final one performed by the implementation after updating the
  393.  aio_errno and aio_result fields. The notification function may send a signal,
  394.  in which case the result will be as in D12. The notification function can (in
  395.  effect) directly run the signal handler that would deal with the asynch I/O
  396.  completion.
  397.  
  398.  To make this approach even more flexible, an atomic_t element can be added to
  399.  struct aiocb to atomically mark the aiocb as completed.
  400.  
  401.  
  402. --------------------------------------------------------------------------
  403. @ 9.2.1.2 o 16
  404. 16: Section 9.2.1.2 page 176 line(s) 93-97
  405.  
  406. OBJECTION:
  407.  
  408.  The consensus in P1003.4 is clearly to not use the file system as the name
  409.  space for their handles.  Unfortunately the current "maybe it's in the file
  410.  system and maybe it's not" semantics only confuses the issue further.
  411.  
  412. ACTION:
  413.  
  414.  Change these lines to say that if {_POSIX_OBJECTS_ARE_FILES} is defined, then
  415.  the names are true path names; otherwise the indicated things are unspecified.
  416.  
  417.  
  418. --------------------------------------------------------------------------
  419. @ 9.2 o 17
  420. 17: Section 9.2 page 179 line(s) 211-214
  421.  
  422. OBJECTION:
  423.  
  424.  We join in UO142.D11. The variety of message passing systems make this an
  425.  unreasonable requirement on implementations.
  426.  
  427. ACTION:
  428.  
  429.  Leave the last close behavior unspecified.
  430.  
  431.  
  432. --------------------------------------------------------------------------
  433. @ 17 o 18
  434. 18: Section 17 page all line(s) all
  435.  
  436. OBJECTION:
  437.  
  438.  Several problems here.
  439.  
  440.  The apparent reason for this chapter was to replace the System V semaphores.
  441.  The only reason that POSIX.4a semaphores aren't a complete replacement is
  442.  that some machines don't have shared memory.  The embedded case can be
  443.  supported using D11 semaphores with some minor changes.
  444.  
  445.  Naming semaphores, while odious, is implementable on top of higher
  446.  performance POSIX.4a semaphores.  Simplification via shared memory semaphores
  447.  is a real benefit to users and implementors.
  448.  
  449.  The goal of being implementable on all systems is met by implementations on
  450.  systems without memory management hardware using pointers in the semaphore
  451.  objects to refer to common synchronization objects, i.e., using an additional
  452.  level of indirection.
  453.  
  454. ACTION:
  455.  
  456.  Define shared memory semaphores as defined on the following manual pages.
  457.  
  458. 1.  sem_init()  Initialize a Semaphore
  459.  
  460.  
  461.  
  462. NAME sem_init
  463. DESCRIPTION sem_init() initializes the named semaphore to a known state.
  464. SYNOPSIS 
  465.  
  466. #include <synch.h>
  467.  
  468. int sem_init(sem_t *sema, int sem_count, int type, void *arg);
  469.  
  470. PROCESSING sem_init(), initializes the semaphore sema of type type to a known
  471.  state.
  472.  
  473. The parameter sem_count must be greater than or equal to zero, defines the
  474. initial count of resources protected by the semaphore. Once initialized, the
  475. semaphore can be used any number of times without being re-initialized. A
  476. semaphore should not be re-initialized while threads are waiting at the
  477. semaphore.
  478.  
  479. If type is USYNC_THREAD the semaphore is initialized for threads within a
  480. single process. Specification of USYNC_PROCESS for the type will initialize
  481. the semaphore for threads across processes.
  482.  
  483. The arg is reserved for future use.
  484.  
  485. All operations on semaphores initialized with sem_init() are non-recursive;
  486. the error check is done under the DEBUG option to detect their recursive use.
  487.  
  488. Statistics and performance data will be collected under the DEBUG option.
  489. OUTPUT On successful completion, sema is initialized and the operation returns
  490. zero. Otherwise, the contents of sema are unchanged and an appropriate error
  491. indication value is returned.  ERROR/DIAGNOSTICS If any of the following
  492. conditions is detected, sem_init() fails and returns the corresponding value:
  493.  
  494. EINVAL    Invalid argument specified.
  495.  
  496. EBUSY     An attempt is made to initialize a semaphore while threads are waiting
  497.           at the semaphore.
  498.  
  499. SEE ALSO sem_wait , sem_post , sem_trywait , sem_destroy , POSIX.4/D12 Section
  500. 17.2.1.
  501.  
  502.  
  503. 2.  sem_wait()  Wait on a Semaphore
  504.  
  505. NAME sem_wait
  506.  
  507. DESCRIPTION sem_wait() is used to claim resources under the semaphore's
  508. control.
  509.  
  510. SYNOPSIS 
  511.  
  512. #include <synch.h>
  513.  
  514. int sem_wait(sem_t *sema);
  515.  
  516. PROCESSING sem_wait() acquires sema by decrementing the semaphore value. If
  517. the resulting value is greater than or equal to zero, it returns success
  518. having acquired sema. If the semaphore count is zero upon entry, sem_wait()
  519. suspends execution of the calling thread and places it on a queue associated
  520. with sema where it remains until sema becomes available to the caller (i.e.,
  521. the count is greater than zero), at which point sem_wait() decrements the
  522. count and returns success having acquired sema. (A negative value for the
  523. count is illegal.)
  524.  
  525. sema must previously have been initialized.
  526.  
  527. In general, this operation is used to block wait for an event, or when a
  528. critical section is long.
  529.  
  530. This operation keeps track of statistics and performance data under the DEBUG
  531. option.
  532.  
  533. If a thread waiting on a semaphore is interrupted by a signal, the signal
  534. handler will run, but sem_wait is always restarted so the semaphore is held on
  535. return.  OUTPUT The operation returns zero if the semaphore is successfully
  536. acquired.  ERROR/DIAGNOSTICS If any of the following conditions is detected,
  537. sem_wait() fails and returns the corresponding value:
  538.  
  539. EINVAL    Invalid argument specified.
  540.  
  541. SEE ALSO sem_init , sem_post , sem_trywait , sem_destroy , POSIX.4/D12 Section
  542. 17.2.4.
  543.  
  544. COMMENTS While a sem_wait can be interrupted by a signal or a fork, an
  545. EINTR is never returned to the user: the wait must be restarted.
  546.  
  547.  
  548. 3.  sem_trywait()  Conditional Locking
  549.  
  550. NAME sem_trywait
  551.  
  552. DESCRIPTION sem_trywait() is used to claim resources under the semaphore's
  553. control.
  554.  
  555. SYNOPSIS 
  556.  
  557. #include <synch.h>
  558.  
  559. int sem_trywait(sem_t *sema);
  560.  
  561. PROCESSING sem_trywait() makes a single attempt to acquire the lock sema, but
  562. does not block in the case of a failure. The sema must have been previously
  563. initialized.
  564.  
  565. This operation keeps track of statistics and performance data under the DEBUG
  566. option.  OUTPUT The operation returns zero if the lock is successfully
  567. acquired and an appropriate error indication value if the lock could not be
  568. acquired.  ERROR/DIAGNOSTICS If any of the following conditions is detected,
  569. sem_trywait() fails and returns the corresponding value:
  570.  
  571. EINVAL    Invalid argument specified.
  572. EBUSY     The semaphore is in the locked state.
  573.  
  574. SEE ALSO sem_init , sem_wait , sem_post , sem_destroy , POSIX.4/D12 Section
  575. 17.2.4.
  576.  
  577.  
  578. 4.  sem_post()  Unlock a Semaphore
  579.  
  580. NAME sem_post
  581.  
  582. DESCRIPTION sem_post() releases a lock by incrementing the count value of the
  583. semaphore.
  584.  
  585. SYNOPSIS 
  586.  
  587. #include <synch.h>
  588.  
  589. int sem_post(sem_t *sema);
  590.  
  591. PROCESSING sem_post() releases a resource under the semaphore control sema
  592. (increments the semaphore value) acquired by a previous call to either
  593. sem_wait(), or sem_trywait(), and if the new count value is less than or equal
  594. to zero, the next thread waiting at the semaphore will be made runnable.
  595.  
  596. sem_post() will fail when releasing a resource would over-increment the
  597. semaphore count value and the DEBUG mode is enabled.
  598.  
  599. This operation keeps track of statistics and performance data under the DEBUG
  600. option.
  601.  
  602. If more than one thread is waiting, release from the blocked group is
  603. scheduling policy specific for bound threads, and may be dependent on
  604. scheduling parameters for multiplexed threads.  OUTPUT On successful
  605. completion, the operation returns zero.  ERROR/DIAGNOSTICS If any of the
  606. following conditions is detected, sem_post() fails and returns the
  607. corresponding value:
  608.  
  609. EINVAL    Invalid argument specified.
  610. ENOLCK    The semaphore is not in the locked state.
  611.  
  612. SEE ALSO sem_init , sem_wait , sem_trywait , sem_destroy , POSIX.4/D12 Section
  613. 17.2.5.
  614.  
  615.  
  616. 5.  sem_destroy()  Destroy a Semaphore
  617.  
  618. NAME sem_destroy
  619.  
  620. DESCRIPTION sem_destroy() attempts to destroy a semaphore.
  621.  
  622. SYNOPSIS 
  623.  
  624. #include <synch.h>
  625.  
  626. int sem_destroy(sem_t *sema);
  627.  
  628. PROCESSING sem_destroy() attempts to destroy a semaphore, i.e., free up all
  629. dynamically allocated resources associated with the given semaphore, and/or
  630. invalidates statically allocated object (e.g., it will free up the statistics
  631. buffer dynamically allocated under the DEBUG option).
  632.  
  633. The parameter sema identifies the semaphore to be destroyed.  OUTPUT On
  634. successful completion, the operation succeeds and returns zero.
  635. ERROR/DIAGNOSTICS If any of the following conditions is detected,
  636. sem_destroy() fails and returns the corresponding value:
  637.  
  638. EINVAL    Invalid argument specified.
  639. EBUSY     An attempt to destroy semaphore was made while the semaphore was 
  640.           locked by another thread.
  641.  
  642. SEE ALSO sem_init , sem_wait , sem_trywait , sem_post , POSIX.4/D12 Section
  643. 17.2.2.
  644.  
  645. --------------------------------------------------------------------------
  646. @ 17 o 19
  647. 19: Section 17 page all line(s) all
  648.  
  649. OBJECTION:
  650.  
  651.  sem_lock, sem_trylock, and sem_unlock are bad names for counting semaphores.
  652.  Existing practice would indicate use of either P & V or post and wait. P and
  653.  V are easily confused, therefore...
  654.  
  655. ACTION:
  656.  
  657.  Use the names sem_post, sem_wait, and sem_trywait.
  658.  
  659. --------------------------------------------------------------------------
  660. @ 17.2 o 20
  661. 20: Section 17.2 page 89-93 line(s) 12-147
  662.  
  663. OBJECTION:
  664.  
  665.  The "harmonization" between .4 semaphores and .4a synchronization primitives
  666.  is inadequate. It forces the application to explicitly name each semaphore
  667.  that span process boundaries. It does not provide adequate protection for
  668.  using inter-process semaphores in that protection cannot be set. In addition
  669.  it conflicts with the obvious way one would use POSIX.4a style semaphores.
  670.  
  671. ACTION:
  672.  
  673.  Delete sem_open(), sem_destroy(), and sem_unlink(). Replace them with
  674.  
  675.   pthread_semattr_init(pthread_semattr_t *attr);
  676.   pthread_semattr_destroy(pthread_semattr_t *attr);
  677.   pthread_semattr_getpshared(pthread_semattr_t *attr, int *pshared);
  678.   pthread_semattr_setpshared(pthread_semattr_t *attr, int pshared);
  679.   pthread_sem_init(pthread_sem_t *sem, pthread_semattr_t *attr);
  680.   pthread_sem_destroy(pthread_sem_t *sem);
  681.  
  682.  When semaphores are to be shared across process boundaries then they are
  683.  placed in a shared memory object or mapped file. This provides a global name
  684.  for independent processes to use, and it provided a well-defined protection
  685.  mechanism.
  686.  
  687.  
  688. --------------------------------------------------------------------------
  689. @ 20 o 21
  690. 21: Section 20 page 117 line(s) 2-14
  691.  
  692. OBJECTION:
  693.  
  694.  Normative text has been moved to the rationale regarding the following
  695.  behaviors: - writes to memory shared between processes appear in the other
  696.  mapping processes (lines 465- 469).  - behavior on protected or unmapped
  697.  references (lines 486-496).
  698.  
  699. ACTION:
  700.  
  701.  Add the lines specified above after line 14.
  702.  
  703. --------------------------------------------------------------------------
  704. @ 20 o 22
  705. 22: Section 20 page 117 line(s) 2-14
  706.  
  707. OBJECTION:
  708.  
  709.  The text does not specify that the address of the reference that caused the
  710.  SIGBUS or SIGSEGV should be delivered to the signal handler that specifies
  711.  SA_SIGINFO.
  712.  
  713. ACTION:
  714.  
  715.  Add after line 14 something like:
  716.  
  717.  When a SIGSEGV or SIGBUS is delivered and the SA_SIGINFO flag is set, the
  718.  sival_ptr member of sigev_value shall be set to the address of the reference
  719.  that caused the signal to be generated.  The address may rounded down to the
  720.  nearest {_SC_PAGESIZE} boundary.
  721.  
  722.  
  723. --------------------------------------------------------------------------
  724. @ 21 o 23
  725. 23: Section 21 page all line(s) all
  726.  
  727. OBJECTION:
  728.  
  729.  The scheduling interfaces have become more cumbersome as the drafts have
  730.  progressed. It is time for a simplification.
  731.  
  732. ACTION:
  733.  
  734.  Replace this chapter's interfaces with a parallel to the Pthreads POSIX.4a
  735.  CRB proposals. The interfaces that should be supported are
  736.  
  737.  yield()
  738.  
  739.  set_sched_attr() for startup
  740.  
  741.  inheritance from creator
  742.  
  743.  set_self_scheduler (struct...)
  744.  
  745.  get_self_scheduler ( struct *... )
  746.  
  747.  set_scheduler (pid_t, struct...)
  748.  
  749.  get_scheduler (pid_t, struct *... )
  750.  
  751. --------------------------------------------------------------------------
  752. @ 21 o 24
  753. 24: Section 21 page all line(s) all
  754.  
  755. OBJECTION:
  756.  
  757.  We join in Unresolved Objections 81, 89, 95, and 97.
  758.  
  759.  As stated in UO89.D11, you can't have your cake and eat it too -- SCHED_OTHER
  760.  is not an escape from realtime scheduling. The reviewer's response
  761.  contradicts the statement in D12 that SCHED_OTHER may be the same as either
  762.  SCHED_FIFO or SCHED_RR. You can't have it both ways...
  763.  
  764.  UO97.D11 brings up the identification of schedulers problem. A simple
  765.  implementation could define SCHED_OTHER to be zero, SCHED_FIFO to be zero,
  766.  and SCHED_RR to be one. How do you tell what the result of a getscheduler()
  767.  call is? Remember, the value of SCHED_OTHER is a compile-time constant.
  768.  
  769.  
  770. ACTION:
  771.  
  772.  Change all occurrences of SCHED_OTHER to SCHED_DEFAULT. In the alternative,
  773.  define a new interface sched_default() which returns an indicator of the
  774.  default scheduler for the implementation. This should probably be a string,
  775.  but a name would be even better. This eliminates the need for a SCHED_OTHER
  776.  constant.
  777.  
  778.  
  779. --------------------------------------------------------------------------
  780. @ 21 o 25
  781. 25: Section 21 page all line(s) all
  782.  
  783. OBJECTION:
  784.  
  785.  The use of SCHED_OTHER is confusing. SCHED_OTHER is simply a placeholder for
  786.  "some scheduling algorithm that may be different or not different from
  787.  SCHED_FIFO and SCHED_RR". This suggests both that SCHED_OTHER is a name for
  788.  some specific scheduling algorithm AND that SCHED_OTHER is a name for some
  789.  selectable scheduling algorithm that may be different from SCHED_FIFO and
  790.  SCHED_RR.
  791.  
  792.  Unfortunately, SCHED_OTHER can't be both. The apparent meaning is of some
  793.  system-defined policy that is neither FIFO nor RR, but over-generalization in
  794.  the text of this section makes that incorrect as well.  A more appropriate
  795.  name is "SCHED_DEFAULT." The reviewer's comments on UO81.D11 is not
  796.  persuasive. Perhaps another name would be acceptable to the balloting group?
  797.  We believe that SCHED_DEFAULT is the best that has been proposed so far.
  798.  
  799. ACTION:
  800.  
  801.  Rename SCHED_OTHER to SCHED_DEFAULT in the entire chapter.
  802.  
  803. --------------------------------------------------------------------------
  804. @ 22 o 26
  805. 26: Section 22 page 168- line(s) 36ff
  806.  
  807. OBJECTION:
  808.  
  809.  Timer firing notification should be should be be a function as in our
  810.  proposal for asynch I/O. This style of notification allows flexible
  811.  prioritization of timer completion events without the overhead of sending a
  812.  signal.
  813.  
  814. ACTION:
  815.  
  816.  A simpler solution, similar to that provided in unresolved objection
  817.  UO148.D11 but accidentally deleted by the Unresolved Objections Editor, is to
  818.  provide a function to be called when the timer fires.
  819.  
  820.  Replace the evp argument with a pointer to a function with a single parameter
  821.  of type clock_t. Change p171, lines 146-148 and 153-162 to match. Correct the
  822.  prototype.
  823.  
  824.  
  825. --------------------------------------------------------------------------
  826. @ 22.2 c 27
  827. 27: Section 22.2 page 171 line(s) 137
  828.  
  829. EDITORIAL COMMENT:
  830.  
  831.  The type of the *evp parameter is missing. If our other objections are not
  832.  accepted, this should read ...  struct sigevent *evp.
  833.  
  834.  
  835. --------------------------------------------------------------------------
  836. @ 23 o 28
  837. 28: Section 23 page all line(s) all
  838.  
  839. OBJECTION:
  840.  
  841.  IPC message notification should be a function as in our proposal for asynch
  842.  I/O. This style of notification allows flexible prioritization of IPC
  843.  completion events without the overhead of sending a signal.
  844.  
  845. ACTION:
  846.  
  847.  Change the notification parameter on p191 lines 16-17 to type pointer to
  848.  function with parameter mqd_t.  Change lines 347-354 to match the new meaning
  849.  for notification.
  850.  
  851.  
  852. --------------------------------------------------------------------------
  853. @ 23 o 29
  854. 29: Section 23 page all line(s) all
  855.  
  856. OBJECTION:
  857.  
  858.  The message-received notification is within a process, and (rather than the
  859.  optional realtime signals) should be as we have proposed for asynch I/O.
  860.  
  861. --------------------------------------------------------------------------
  862. @ 23 o 30
  863. 30: Section 23 page 191-210 line(s) 1-656
  864.  
  865. OBJECTION:
  866.  
  867.  In reference to D11 Unresolved Objections 133, 142:
  868.  
  869.  The interfaces in this chapter are not based on current practice. In
  870.  particular, none use the file system as the name space for their handles, for
  871.  good reason. It confuses the semantics of both the message queues and the
  872.  file system and is not extensible over the network. The current "maybe it's
  873.  in the file system and maybe it's not" semantics only confuses the issue
  874.  further.
  875.  
  876.  I believe that it is possible to meet all the requirements expressed by the
  877.  rationale by minimal extensions to the BSD sockets interface or the X/Open
  878.  XTI interface. Indeed, the working group has recognized this possibility and
  879.  asked .12 to do so. It should be possible to meet the valid real time
  880.  requirements through extensions to existing, more general interfaces, rather
  881.  than through introduction of a new (although much improved from previous
  882.  drafts!) set of interfaces.
  883.  
  884.  At the very least, any new .4 IPC interface should be implementable entirely
  885.  on top of sockets, or in terms of threads and shared memory.
  886.  
  887.  In summary, We believe that no convincing rationale has been presented for
  888.  the addition of completely new IPC interfaces.
  889.  
  890. ACTION:
  891.  
  892.  The proposed interfaces should be replaced with one based on an existing
  893.  interface, ideally one that has potential to be used in a distributed
  894.  environment, including those in which the file systems are not shared (i.e.
  895.  are not syntactically linked with the file system). Our preferred candidate
  896.  would be to utilize the BSD sockets and X/Open XTI interfaces as being
  897.  standardized by .12, with the addition of a real time protocol.
  898.  
  899.  Alternately, this objection can be satisfied by deleting the IPC chapter.
  900.  
  901.  
  902. --------------------------------------------------------------------------
  903. @ 23.1.1 o 31
  904. 31: Section 23.1.1 page 192 line(s) 26-28,46-53
  905.  
  906. OBJECTION:
  907.  
  908.  In reference to D11 Unresolved Objections 134, 136:
  909.  
  910.  The mq_sendwait, mq_rcvwait, and mq_curmsgs fields cannot be counted on to
  911.  remain fixed between a reading of the fields and any subsequent action within
  912.  a program. Therefore, it's not clear what use any program could reliably make
  913.  of this data. The application can only tune itself if it has control over all
  914.  consumers of the queue and diagnosis is not in the province of POSIX.
  915.  
  916.  Also, counting the number of waiting processes precludes implementations in
  917.  shared memory using pthreads-like synchronization primitives. First, some
  918.  synchronization primitives don't keep track of the number of sleeping
  919.  processes (e.g. slow spin). Also, it is difficult or impossible to
  920.  distinguish multiple sleeping threads within a process from separate sleeping
  921.  processes.
  922.  
  923. ACTION:
  924.  
  925.  These fields should be removed.
  926.  
  927.  
  928. --------------------------------------------------------------------------
  929. @ 23.2 c 32
  930. 32: Section 23.2 page 201 line(s) 336
  931.  
  932. EDITORIAL COMMENT:
  933.  
  934.  The type of the *notification parameter is missing. If our other objections
  935.  are not accepted, this should read ... struct sigevent *notification.
  936.  
  937.  
  938. --------------------------------------------------------------------------
  939. @ 23.2.7 o 33
  940. 33: Section 23.2.7 page 202-203 line(s) 370-426
  941.  
  942. OBJECTION:
  943.  
  944.  In reference to D11 Unresolved Objection 140:
  945.  
  946.  The function mq_setattr() provides the capability to dynamically modify the
  947.  message queue attributes, such as the message maximum size or maximum number
  948.  of messages. Although this functionality represents a higher degree of
  949.  flexibility, in our opinion, this flexibility does not justify the efficiency
  950.  burden imposed on the implementation that has to deal with the possibility of
  951.  dynamic sizing of the message queue objects. This represents a source for
  952.  more indeterminate time in the message queuing and dequeuing operations
  953.  (which could be concurrently executed with this dynamic reconfiguration of
  954.  the message queue) and a source of complexity and inefficiency for the
  955.  implementation.
  956.  
  957.  Also, making the ability to set the max number of messages and max message
  958.  size implementation defined only makes this ability unusable by portable
  959.  applications, and points out that there is no true need for this ability.
  960.  
  961. ACTION:
  962.  
  963.  Delete the mq_setattr() function, and make the queue attributes static.
  964.  
  965.  
  966. --------------------------------------------------------------------------
  967. @ 24 o 34
  968. 34: Section 24 page all line(s) all
  969.  
  970. OBJECTION:
  971.  
  972.  Realtime files confuse the desired objective -- predictable performance --
  973.  with mechanisms that have historically been used to obtain predictable
  974.  performance from disks and/or file systems. This confusion is most evident in
  975.  the requirements laid on implementations to place data and to organize
  976.  descriptive information in particular ways. Current disk subsystem
  977.  technology, including SCSI, RAID, advanced striping, journaling, and recovery
  978.  technology render much of the low-level detail obsolescent if not obsolete.
  979.  
  980.  The specification of low-level architecture and behavior stifle innovation
  981.  and leave little room to achieve the real goals of fast, predictable access
  982.  to data.
  983.  
  984. ACTION:
  985.  
  986.  Delete this chapter. In the alternative, define in rationale only performance
  987.  metrics for vendor/technology comparison, and forward them to a benchmarking
  988.  group.
  989.  
  990.  Alternatives using fcntl() to pass hints on access characteristics are
  991.  presented in other objections.
  992.  
  993.  
  994. --------------------------------------------------------------------------
  995. @ 24 o 35
  996. 35: Section 24 page 228-230 line(s) 578-625
  997.  
  998. OBJECTION:
  999.  
  1000.  rf_getbuf and rf_freebuf are new interface that are not needed. The usage can
  1001.  be replaced with aligned versions of malloc as used in SunOS and other
  1002.  systems.
  1003.  
  1004. ACTION:
  1005.  
  1006.  Use this existing practice interface or delete this text.
  1007.  
  1008.  
  1009. --------------------------------------------------------------------------
  1010. @ 24 o 36
  1011. 36: Section 24 page all line(s) all
  1012.  
  1013. OBJECTION:
  1014.  
  1015.  The interfaces presented in Section 24 are overly complex to meet the stated
  1016.  needs. The stat structure (defined in <stat.h>) can return the suggested I/O
  1017.  blocksize in the field st_blksize. This allows determination on a
  1018.  file-by-file basis.
  1019.  
  1020.  The existing interface fcntl() can be used to advises the implementation
  1021.  about the expected usage pattern for a file descriptor. The arguments that
  1022.  fcntl() is not type-safe and should be discouraged are not compelling --
  1023.  fcntl has been a general file management interface for many years, and
  1024.  programmers have learned to deal with its impurities.
  1025.  
  1026.  We differ with unresolved objection UO178.D11 in that we would use only
  1027.  F_ADVISE, deleting F_DONTNEED and F_WILLNEED from that objection. We find
  1028.  that the use of struct flock is unnecessary overloading.
  1029.  
  1030. ACTION:
  1031.  
  1032.  Follow the prescription in UO178.D11 with the exception of F_DONTNEED and
  1033.  F_WILLNEED.
  1034.  
  1035.  
  1036. --------------------------------------------------------------------------
  1037. @ 24 o 37
  1038. 37: Section 24 page all line(s) all
  1039.  
  1040. OBJECTION:
  1041.  
  1042.  We partially join in unresolved objections UO168.D11, UO171.D11, UO177.D11,
  1043.  and UO178.D11. So- called "direct I/O" does not belong here. It is
  1044.  disingenuous to claim (response to UO171.D11) that buffering the requests
  1045.  anyway is an acceptable implementation. We challenge the technical reviewer
  1046.  to give a cogent explanation of how manipulating the caching strategy and the
  1047.  buffering strategy separately will give DETERMINISTIC and PORTABLE behavior.
  1048.  
  1049.  This nonsense is not consistent with the claimed rationale for providing the
  1050.  functionality, and tries to solve problems more appropriately solved by
  1051.  standardized performance metrics/methodology and market pressures.
  1052.  
  1053.  Moreover, capabilities for establishing similar functionality are already
  1054.  available on existing UNIX Systems, e.g., use of raw disk partitions.
  1055.  Complicating the I/O subsystem by adding per-file tunable buffering seems a
  1056.  mistake.
  1057.  
  1058. ACTION:
  1059.  
  1060.  Delete all references to "direct I/O" including these lines, definitions, and
  1061.  rationale.
  1062.  
  1063.  
  1064. --------------------------------------------------------------------------
  1065. @ 24 c 38
  1066. 38: Section 24 page 24.5 line(s) 234
  1067.  
  1068. EDITORIAL COMMENT:
  1069.  
  1070.  If our objections relating to direct I/O are accepted, direct I/O is not used
  1071.  in normative text, so this reference in the rationale should be deleted.
  1072.  
  1073. ACTION:
  1074.  
  1075.  Delete lines 785-787.
  1076.  
  1077.  
  1078. --------------------------------------------------------------------------
  1079. @ 24 o 39
  1080. 39: Section 24 page all line(s) all
  1081.  
  1082. OBJECTION:
  1083.  
  1084.  We join in unresolved objections UO169.D11, 170-175, 179, and 180.
  1085.  
  1086.  The reviewer's response to UO170.D11 adds useful information on some existing
  1087.  systems that support "these facilities." The reviewer later mentions that
  1088.  Digital has implemented D9 interfaces on a version of VMS, which further
  1089.  weakens the claim that "these facilities" are necessary and broadly
  1090.  supported. The dismissal of "realtime file systems" ignores the typical
  1091.  implementation of files on modern operating systems using a Virtual File
  1092.  System sort of architecture. The mixing of multiple types of files in a
  1093.  directory hierarchy may preclude a high performance implementation and may,
  1094.  in fact, affect all uses of files due to the support of so-called "realtime
  1095.  files."
  1096.  
  1097.  The argument in UO172.D11 is compelling. Not only are the facilities
  1098.  insufficient to meet the claimed need, they cannot be made complete by
  1099.  breaking up the capabilities buffer.
  1100.  
  1101.  The reviewer's response to UO173.D11 is identical to that for UO172.D11, and
  1102.  does not address the point of UO173. What portable actions can be taken by an
  1103.  application? The capabilities buffer is certainly "a zoo" even after its
  1104.  separation. The syntactic expression does not serve to hide semantic
  1105.  (over-)complexity.
  1106.  
  1107.  We have observed elsewhere that the 'aligned allocator' rf_getbuf should be
  1108.  replaced with an aligned malloc as used in SunOS. (UO174.D11)
  1109.  
  1110.  UO175.D11 and the essentially identical UO179.D11 give additional support to
  1111.  our general comments on this Section.
  1112.  
  1113. ACTION:
  1114.  
  1115.  Delete this chapter. Forward the performance metrics to a standards and/or
  1116.  benchmarking group. (Retain the benchmarks in the rationale if desired.)
  1117.  
  1118.  
  1119. --------------------------------------------------------------------------
  1120. @ 24.3 o 40
  1121. 40: Section 24.3 page 228 line(s) 578-625
  1122.  
  1123. OBJECTION:
  1124.  
  1125.  The functions rf_getbuf() and rf_freebuf() should be compatible with existing
  1126.  practice for aligned allocation.
  1127.  
  1128. ACTION:
  1129.  
  1130.  Replace these names with valloc() as valloc(size) does an aligned allocation.
  1131.  
  1132. --------------------------------------------------------------------------
  1133. --
  1134. Robert L. Knighten                 | knighten@ssd.intel.com
  1135. Intel Supercomputer Systems Division | 
  1136. 15201 N.W. Greenbrier Pkwy.         | (503) 629-4315
  1137. Beaverton, Oregon  97006         | (503) 629-9147 [FAX]
  1138.  
  1139.  
  1140. Volume-Number: Volume 27, Number 66
  1141.  
  1142.