From baker@dad.cs.fsu.edu Thu Apr 16 10:27:29 1998 Return-Path: Received: from intermetrics.com by dsd.camb.inmet.com (SMI-8.6/SMI-SVR4) id KAA24372; Thu, 16 Apr 1998 10:27:28 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by intermetrics.com (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id KAA18174 for ; Thu, 16 Apr 1998 10:27:26 -0400 (EDT) Received: from dad.cs.fsu.edu by sw-eng.falls-church.va.us (8.8.8/) id OAA19713; Thu, 16 Apr 1998 14:23:40 GMT Received: by dad.cs.fsu.edu (SMI-8.6/SMI-SVR4) id KAA20439; Thu, 16 Apr 1998 10:27:15 -0400 Date: Thu, 16 Apr 1998 10:27:15 -0400 From: Ted Baker Message-Id: <199804161427.KAA20439@dad.cs.fsu.edu> To: ada-comment@sw-eng.falls-church.va.us, yoder@decada.ENET.dec.com Subject: RE: AI-165 revised content-length: 2525 !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 <> !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 From yoder@decada.ENET.dec.com Thu Apr 16 12:03:01 1998 Return-Path: Received: from intermetrics.com by dsd.camb.inmet.com (SMI-8.6/SMI-SVR4) id MAA24743; Thu, 16 Apr 1998 12:03:00 -0400 Received: from sw-eng.falls-church.va.us (ns1.sw-eng.falls-church.va.us [199.75.54.2]) by intermetrics.com (8.9.0.Beta3/8.9.0.Beta3) with ESMTP id MAA21356 for ; Thu, 16 Apr 1998 12:02:58 -0400 (EDT) Received: from mail13.digital.com by sw-eng.falls-church.va.us (8.8.8/) id PAA22527; Thu, 16 Apr 1998 15:59:11 GMT Received: from us2rmc.zko.dec.com (us2rmc.zko.dec.com [16.33.16.101]) by mail13.digital.com (8.8.8/8.8.8/WV1.0d) with SMTP id MAA32169; Thu, 16 Apr 1998 12:02:45 -0400 (EDT) Received: from decada.enet by us2rmc.zko.dec.com (5.65/rmc-22feb94) id AA24748; Thu, 16 Apr 98 12:02:37 -0400 Message-Id: <9804161602.AA24748@us2rmc.zko.dec.com> Received: from decada.enet; by us2rmc.enet; Thu, 16 Apr 98 12:02:44 EDT Date: Thu, 16 Apr 98 12:02:44 EDT From: MFY To: baker@dad.cs.fsu.edu, ada-comment@sw-eng.falls-church.va.us Apparently-To: ada-comment@sw-eng.falls-church.va.us, baker@dad.cs.fsu.edu Subject: RE: AI-165 revised content-length: 1602 !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 <> !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.