From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,3ccb707f4c91a5f2
X-Google-Attributes: gid103376,public
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Unbounded strings (Was: Java vs Ada 95 (Was Re: Once again,
 Ada absent from DoD SBIR solicitation))
Date: 1996/11/25
Message-ID: <EACHUS.96Nov25163413@spectre.mitre.org>#1/1
X-Deja-AN: 200708808
references: <325BC3B3.41C6@hso.link.com> <dewar.848202876@merv>
 <E11C57.EF2@world.std.com>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1996-11-25T00:00:00+00:00
List-Id: <comp.lang.ada>



   I said:

 > "      Suppose one task creates an unbounded string, and passes it to
 > another task through a rendezvous.  Both task create copies, then
 > modify different sections of the original string.  Definitely
 > erroneous, but it will make lazy reference counting visible."

   Robert Dewar said:

 > The "definitely erroneous" here seems too strong to me. The point is that
 > we have two basic possible semantics of unbounded strings, one is to copy
 > on all assignments, and the other is to share copies, and copy only on a
 > modification.

   I think Robert, you may need to reread my example.  If the two
tasks modified the copies, then the erroneousness would be
questionable.  But I have both tasks updating the same value without
an intervening synchronization point.  THAT is erroneous if anything
is.  The copies allow me to determine later whether lazy updating is
used, but are not what makes the example erroneous.  Even if the areas
modified are non-overlapping, an implementation can write words
instead of bytes.

   My point was that the program must be erroneous for lazy copies to
be visible with the given implementation strategy.  (There are other
methods involving unchecked conversions, but the addresses you get are
erroneous, because Unchecked_Conversion is not required to return
values by reference.)

   Other than that, I think Robert Dewar and I are in strong
agreement.  What happens if tasks share values without explicit
synchronization can't be used to govern how a library package is
implemented.  We can only reason about the behavior in cases where the
conditions in A(3) hold.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...