home *** CD-ROM | disk | FTP | other *** search
/ Programmer's ROM - The Computer Language Library / programmersrom.iso / ada / lrm / chap09.err < prev    next >
Encoding:
Text File  |  1988-05-03  |  11.2 KB  |  266 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.                             Errata for changes to Chapter 9 version 21
  7.  
  8.  
  9.  
  10.  
  11. 9  (paragraph 5)9  (paragraph 5)9  (paragraph 5)
  12.  
  13.  
  14. Parallel  tasks  (parallel   logical   processors)   may   be   implemented   on   multicomputers,
  15. multiprocessors, or with interleaved execution on a single physical________ processor_________.  On the other hand,
  16. whenever  an  implementation  can  detect  that  the same effect can be guaranteed if parts of the
  17. actions of a given task are executed by different physical processors acting in parallel,  it  may
  18. choose  to  execute  them  in  this  way;  in such a case, several physical processors implement a
  19. single logical processor.
  20.  
  21.  
  22.  
  23.  
  24. 9  (paragraph 6)9  (paragraph 6)9  (paragraph 6)
  25.  
  26.  
  27. References:___________ abort statement 9.10, accept statement 9.5, delay statement 9.6, entry 9.5, entry call
  28. statement 9.5, generic unit 12, package 7, parameter  in  an  entry  call  9.5,  program  unit  6,
  29. rendezvous 9.5, select statement 9.7, subprogram 6, task body 9.1, task specification 9.1
  30.  
  31.  
  32.  
  33.  
  34. 9.1  Task Specifications and Task Bodies (paragraph 4)9.1  Task Specifications and Task Bodies (paragraph 4)9.1  Task Specifications and Task Bodies (paragraph 4)
  35.  
  36.  
  37. The  simple name at the start of a task body must repeat the task unit identifier.  Similarly if a
  38. simple name appears at the end of the task specification or body, it must  repeat  the  task  unit
  39. identifier.  Within a task body, the name of the corresponding task unit can also be used to refer
  40. to the task object that designates the task currently executing the body;  furthermore, the use of
  41. this name as a type mark is not allowed within the task unit itself.
  42.  
  43.  
  44.  
  45. 9.2  Task Types and Task objects (paragraph 1)9.2  Task Types and Task objects (paragraph 1)9.2  Task Types and Task objects (paragraph 1)
  46.  
  47.  
  48. A task type is a limited type (see 7.4.4).  Hence neither assignment nor the predefined comparison
  49. for  equality and inequality are defined for objects of task types;  moreover, the mode outoutout is not
  50. allowed for a formal parameter whose type is a task type.
  51.  
  52.  
  53.  
  54. 9.3  Task Execution - Task Activation (paragraph 3)9.3  Task Execution - Task Activation (paragraph 3)9.3  Task Execution - Task Activation (paragraph 3)
  55.  
  56.  
  57. Should an exception be raised by the activation of  one  of  these  tasks,  that  task  becomes  a
  58. completed  task (see 9.4);  other tasks are not directly affected.  Should one of these tasks thus
  59. become completed during its activation, the exception TASKING_ERROR is raised upon  conclusion  of
  60. the  activation of all of these tasks (whether successfully or not);  the exception is raised at a
  61. place that is immediately before the first statement following the declarative  part  (immediately
  62. after  the reserved word beginbeginbegin).  Should several of these tasks thus become completed during their
  63. activation, the exception TASKING_ERROR is raised only once.
  64.  
  65.  
  66.  
  67. -1                                              Task Execution - Task Activation (paragraph 3) 9.3
  68.  
  69.  
  70.  
  71.  
  72. 9.3  Task Execution - Task Activation (paragraph 4)9.3  Task Execution - Task Activation (paragraph 4)9.3  Task Execution - Task Activation (paragraph 4)
  73.  
  74.  
  75. Should an exception be raised by the elaboration of a declarative part or  package  specification,
  76. then  any  task  that  is created (directly or indirectly) by this elaboration and that is not yet
  77. activated becomes terminated and is therefore never activated (see section 9.4 for the  definition
  78. of a terminated task).
  79.  
  80.  
  81.  
  82. 9.4  Task Dependence - Termination of Tasks (paragraph 4)9.4  Task Dependence - Termination of Tasks (paragraph 4)9.4  Task Dependence - Termination of Tasks (paragraph 4)
  83.  
  84.  
  85. Furthermore,  if  a  task  depends on a given master that is a block statement executed by another
  86. master, then the task depends also on this other master, in an indirect manner;  the same holds if
  87. the given master is a subprogram called by another master, and if the given master is a task  that
  88. depends  (directly  or  indirectly) on another master.  Dependences exist for objects of a private
  89. type whose full declaration is in terms of a task type.
  90.  
  91.  
  92.  
  93.  
  94. 9.4  Task Dependence - Termination of Tasks (paragraph 14)9.4  Task Dependence - Termination of Tasks (paragraph 14)9.4  Task Dependence - Termination of Tasks (paragraph 14)
  95.  
  96.  
  97. For an access type derived from another access type, the corresponding access type  definition  is
  98. that  of  the  parent  type;   the dependence is on the master that elaborates the ultimate parent
  99. access type definition.
  100.  
  101.  
  102.  
  103. 9.5  Entries, Entry Calls, and Accept Statements (paragraph 10)9.5  Entries, Entry Calls, and Accept Statements (paragraph 10)9.5  Entries, Entry Calls, and Accept Statements (paragraph 10)
  104.  
  105.  
  106. Execution of an accept statement starts with the evaluation of the entry index (in the case of  an
  107. entry  of a family).  Execution of an entry call statement starts with the evaluation of the entry
  108. name;  this is followed by any evaluations required for actual parameters in the  same  manner  as
  109. for  a subprogram call (see 6.4).  Further execution of an accept statement and of a corresponding
  110. entry call statement are synchronized.
  111.  
  112.  
  113.  
  114. 9.5  Entries, Entry Calls, and Accept Statements 9.5 (paragraph 22)9.5  Entries, Entry Calls, and Accept Statements 9.5 (paragraph 22)9.5  Entries, Entry Calls, and Accept Statements 9.5 (paragraph 22)
  115.  
  116.  
  117. If the bounds of the discrete range of an entry family are integer  literals,  the  index  (in  an
  118. entry name or accept statement) must be of the predefined type INTEGER (see 3.6.1).
  119.  
  120.  
  121.  
  122.  
  123. 9.7.1  Selective Waits 9.7.1 (paragraph 15)9.7.1  Selective Waits 9.7.1 (paragraph 15)9.7.1  Selective Waits 9.7.1 (paragraph 15)
  124.  
  125.  
  126. References:___________  accept  statement  9.5,  condition  5.3, declaration 3.1, delay expression 9.6, delay
  127. statement 9.6, duration 9.6, entry 9.5, entry call 9.5, entry index 9.5,  program_error  exception
  128. 11.1,  queued  entry  call  9.5, rendezvous 9.5, select statement 9.7, sequence of statements 5.1,
  129. task 9
  130.  
  131.  
  132.  
  133. 9.7.1 Selective Waits 9.7.1 (paragraph 15)                                                      -2
  134.  
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141. 9.10  Abort Statements (paragraph 5)9.10  Abort Statements (paragraph 5)9.10  Abort Statements (paragraph 5)
  142.  
  143.  
  144. Any abnormal task whose execution is suspended at an accept statement, a select  statement,  or  a
  145. delay  statement  becomes  completed;   any abnormal task whose execution is suspended at an entry
  146. call, and that is not yet in a corresponding rendezvous, becomes completed and is removed from the
  147. entry queue;  any abnormal task that has not yet started its  activation  becomes  completed  (and
  148. hence also terminated).  This completes the execution of the abort statement.
  149.  
  150.  
  151.  
  152. 9.10  Abort Statements (paragraph 6)9.10  Abort Statements (paragraph 6)9.10  Abort Statements (paragraph 6)
  153.  
  154.  
  155. The  completion  of  any  other  abnormal  task  need  not  happen  before completion of the abort
  156. statement.  It must happen no later than when the abnormal task reaches  a  synchronization  point
  157. that  is  one of the following: the end of its activation;  a point where it causes the activation
  158. of another task;  an entry call; the start or the end of an accept statement;  a select statement;
  159. a delay statement;  an exception handler;  or an abort statement.  If a task that calls  an  entry
  160. becomes  abnormal while in a rendezvous, its termination does not take place before the completion
  161. of the rendezvous (see 11.5).
  162.  
  163.  
  164.  
  165. 9.10  Abort Statements (paragraph 7)9.10  Abort Statements (paragraph 7)9.10  Abort Statements (paragraph 7)
  166.  
  167.  
  168. The call of an entry of an abnormal task raises the exception TASKING_ERROR at the  place  of  the
  169. call.   Similarly,  the exception TASKING_ERROR is raised for any task that has called an entry of
  170. an abnormal task, if the entry call is still queued or if  the  rendezvous  is  not  yet  finished
  171. (whether  the  entry  call is an entry call statement, or a conditional or timed entry call);  the
  172. exception is raised no later than the completion of the abnormal task.  The value of the attribute
  173. CALLABLE is FALSE for any task that is abnormal (or completed).
  174.  
  175.  
  176.  
  177. 9.10  Abort Statements (pargraph 8 -new)9.10  Abort Statements (pargraph 8 -new)9.10  Abort Statements (pargraph 8 -new)
  178.  
  179.  
  180. If the abnormal completion of a task takes place while the task updates a variable, then the value
  181. of this variable is undefined.
  182.  
  183.  
  184.  
  185. 9.11  Shared Variables (paragraphs 4 5)9.11  Shared Variables (paragraphs 4 5)9.11  Shared Variables (paragraphs 4 5)
  186.  
  187.  
  188.  
  189.   -  If between two synchronization points of a task, this task reads a shared variable whose type
  190.      is a scalar or access type, then the variable is not updated by any other task  at  any  time
  191.      between these two points.
  192.  
  193.   -  If between two synchronization points of a task, this task updates a  shared  variable  whose
  194.      type  is  a scalar or access type, then the variable is neither read nor updated by any other
  195.      task at any time between these two points.
  196.  
  197.  
  198.  
  199. -3                                                          Shared Variables (paragraphs 4 5) 9.11
  200.  
  201.  
  202.  
  203.  
  204. 9.11  Shared Variables (paragraph 10)9.11  Shared Variables (paragraph 10)9.11  Shared Variables (paragraph 10)
  205.  
  206.  
  207. This pragma is allowed only for a variable declared by an object declaration and whose type  is  a
  208. scalar  or  access  type;  the variable declaration and the pragma must both occur (in this order)
  209. immediately within the same declarative part or package specification;   the  pragma  must  appear
  210. before any occurrence of the name of the variable, other than in an address clause.
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226.  
  227.  
  228.  
  229.  
  230.  
  231.  
  232.  
  233.  
  234.  
  235.  
  236.  
  237.  
  238.  
  239.  
  240.  
  241.  
  242.  
  243.  
  244.  
  245.  
  246.  
  247.  
  248.  
  249.  
  250.  
  251.  
  252.  
  253.  
  254.  
  255.  
  256.  
  257.  
  258.  
  259.  
  260.  
  261.  
  262.  
  263.  
  264.  
  265. 9.11 Shared Variables (paragraph 10)                                                            -4
  266.