CVS difference for ais/ai-00165.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00165.txt

--- ais/ai-00165.txt	1998/09/30 23:25:19	1.2
+++ ais/ai-00165.txt	1998/10/01 03:20:19	1.3
@@ -453,3 +453,143 @@
 end A_Prog;
 
 ****************************************************************
+!topic AI-165
+!reference 1998-15845.a Erhard Ploedereder  1998-3-20
+!from Michael Yoder 1998-04-15
+!keywords task attribute,recursion
+<<reference as: 1998-15853.a MFY  1998-4-15>>
+!discussion
+
+There is a minor error in this paragraph:
+
+"If the attribute is of a controlled type or has components of a controlled
+type, then the implicitly invoked user-defined Adjust or Finalize routines
+are presently not forbidden to call on operations of this package for other
+task attributes or even, rather pathologically, for the same task attribute
+of the given task. Whatever locking strategy is applied, the latter will lead
+to a deadlock. The former can lead to a deadlock if the granularity of the 
+lock is any larger than on single attributes of any task, e.g., a lock per
+task or a global run-time lock."
+
+There are no deadlocks when a single global lock is used in the former case above.  Perhaps 
+what was intended was "... or a lock per attribute."  Also, deadlocks are possible even 
+with maximally fine-grained locking, which makes the premise of the following paragraph 
+somewhat unclear:
+
+"It seems unwise to require all implementations to provide a potentially
+expensive very fine-grained locking on attributes merely to guard against
+the fairly rare situation..."
+
+This seems to suggest that fine-grained locking guards against deadlocks, but this is only 
+partly true: what makes deadlocks possible is allowing a lock granularity less than that of 
+a single global lock.  The implementation permission being considered is to allow some 
+deadlocks *in addition* to the ones that are present for cell-level locking, so as to 
+permit implementations to lock by groups.
+
+This counterintuitive aspect of the situation comes from there being a special case: with a 
+single global lock, there cannot be a deadlock, barring circular use; in all other 
+situations, the finer the lock granularity the fewer the potential deadlocks.
+
+****************************************************************
+
+!topic AI-165
+!reference 1998-15845.a Erhard Ploedereder  1998-3-20
+!keywords task attribute,recursion
+!reference 1998-15853.a MFY  1998-4-15
+!from Ted Baker 1998-04-16
+<<reference as: 1998-15854.a Ted Baker  1998-4-16>>
+!discussion
+
+| There is a minor error in this paragraph:
+
+| "If the attribute is of a controlled type or has components of a
+| controlled type, then the implicitly invoked user-defined Adjust
+| or Finalize routines are presently not forbidden to call on
+| operations of this package for other task attributes or even,
+| rather pathologically, for the same task attribute of the given
+| task. Whatever locking strategy is applied, the latter will lead
+| to a deadlock. The former can lead to a deadlock if the
+| granularity of the lock is any larger than on single attributes of
+| any task, e.g., a lock per task or a global run-time lock."
+
+| There are no deadlocks when a single global lock is used in the
+| former case above.
+
+The above sentence does not make sense to me.  As I read it, it is
+saying that if there is a single global run-time lock, there would
+be no deadlock if a task that is holding that lock tries to lock
+the same lock.  I suppose you are assuming that if there is a
+single global lock for the whole runtime system, the problem of
+avoiding eadlock on that lock will necessarily already have been
+solved by some other means?
+
+| Perhaps what was intended was "... or a lock
+| per attribute."  Also, deadlocks are possible even with maximally
+| fine-grained locking, which makes the premise of the following
+| paragraph somewhat unclear:
+
+| "It seems unwise to require all implementations to provide a
+| potentially expensive very fine-grained locking on attributes
+| merely to guard against the fairly rare situation..."
+
+| This seems to suggest that fine-grained locking guards against
+| deadlocks, but this is only partly true: what makes deadlocks
+| possible is allowing a lock granularity less than that of a single
+| global lock.  The implementation permission being considered is to
+| allow some deadlocks *in addition* to the ones that are present
+| for cell-level locking, so as to permit implementations to lock by
+| groups.
+
+| This counterintuitive aspect of the situation comes from there
+| being a special case: with a single global lock, there cannot be a
+| deadlock, barring circular use; in all other situations, the finer
+            ^^^^^^^^^^^^^^^^^^^^
+            RTS "recursion" via finalizers and attributes leads to such
+            circularity.
+
+| the lock granularity the fewer the potential deadlocks.
+
+--Ted
+
+****************************************************************
+
+!topic AI-165
+!reference 1998-15845.a Erhard Ploedereder  1998-3-20
+!keywords task attribute,recursion
+!reference 1998-15853.a MFY  1998-4-15
+!from Ted Baker 1998-04-16
+<<reference as: 1998-15855.a MFY  1998-4-16>>
+!discussion
+
+MY: "There is a minor error in this paragraph:
+
+ 'If the attribute is of a controlled type or has components of a
+ controlled type, then the implicitly invoked user-defined Adjust
+ or Finalize routines are presently not forbidden to call on
+ operations of this package for other task attributes or even,
+ rather pathologically, for the same task attribute of the given
+ task. Whatever locking strategy is applied, the latter will lead
+ to a deadlock. The former can lead to a deadlock if the
+ granularity of the lock is any larger than on single attributes of
+ any task, e.g., a lock per task or a global run-time lock.'
+
+ There are no deadlocks when a single global lock is used in the
+ former case above."
+
+TB: "The above sentence does not make sense to me.  As I read it, it is
+saying that if there is a single global run-time lock, there would
+be no deadlock if a task that is holding that lock tries to lock
+the same lock.  I suppose you are assuming that if there is a
+single global lock for the whole runtime system, the problem of
+avoiding [d]eadlock on that lock will necessarily already have been
+solved by some other means?"
+
+Sorry, I now realize I was making an implicit assumption.  I was assuming
+that an implementation that used one global lock would choose to make it a
+recursive mutex.  This isn't a warranted assumption in the context of
+the discussion, so I'm willing to simply withdraw the comment.
+
+****************************************************************
+
+
+

Questions? Ask the ACAA Technical Agent