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/21
Message-ID: <EACHUS.96Nov20190244@spectre.mitre.org>#1/1
X-Deja-AN: 197736271
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-21T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <E14DCH.5EK@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

  > (Of course I know that two tasks modifying X at the same time would be
  > erroneous.  That's covered by 9.10.)

   And that is EXACTLY the point that kicked all this discussion off.
If an implementation works non-erroneously if the programmer read and
followed 9.10, end of discussion.

   I made an innocent seeming comment that in a tasking environment
the user of Unbounded_Strings HAS to provide a syncronization point
between any two references to the same value from different tasks, one
of which modifies it.  As a result, no simple implementation of
Unbounded_Strings should worry about race conditions.  Of course, any
hidden calls to new must be safe in a tasking environment even if some
other task is also allocating or freeing storage, but that is
different issue, and not local to Unbounded_Strings.

   However, if you do reference counts, there is a very unusual case
that needs to be considered.  But as I pointed out the potential
problems can be cleverly avoided, at the risk of doing some
"unnecessary" copies in race conditions.  So efficient "lazy"
implementations which use reference counting don't incur any
distributed overhead.  The extra copy in a transitive reference case
occurs only 1) if the case required to be non-erroneous occurs, or 2)
in an erroneous program where the reference counting version will do
the "right thing" instead of breaking.

   In other erroneous cases, the reference counting version will
break.  Tough!  The program would be just as erroneous, and more
likely to break if the unbounded string was actually a
Standard.String.  Hmmm... The language lawyer in my immediately reads
that and constructs weird cases.  There are cases where two tasks can
modify different sections of the same string non-erroneously, which
have to be considered erroneous if the operation is performed on an
unbounded string.  Those programs must be considered pathological,
however, I can imagine worst case scenarios where the erroneous
behavior is visible:

      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 I. Eachus

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