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: Java vs Ada 95 (Was Re: Once again,
 Ada absent from DoD SBIR solicitation)
Date: 1996/11/06
Message-ID: <EACHUS.96Nov6151422@spectre.mitre.org>#1/1
X-Deja-AN: 194934174
references: <325BC3B3.41C6@hso.link.com>
 <EACHUS.96Nov1103759@spectre.mitre.org>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1996-11-06T00:00:00+00:00
List-Id: <comp.lang.ada>


In article <1996Nov5.083552.1@eisner> kilgallen@eisner.decus.org (Larry Kilgallen) writes:

  > I think the issue may be one of terminology clash.  What Ada folk
  > call a synchronization point may very well be implemented in what
  > OS folk call a spinlock.  I responded to what struck me as an
  > OS-style discussion (I did not introduce the term spinlock to
  > the thread) using OS-speak.  Perhaps we should be talking
  > about the overhead of a "synchronization point", but the
  > original claim was that it can be cheap where there is no
  > contention, so if nobody disagrees we can forget the term
  > "spinlock" was ever mentioned :-)

     No, actually a synchronization point in Ada-speak is where two
tasks interact and therefore the user can make some assumptions about
the order in which things happen.  The actual synchronization point
can be a task creation, termination, abort, rendezvous, etc., which
will be implemented in part using OS primitives.

    But my real point was that from the user's point of view an
Ada-defined synchronization point for a task can't happen in the
middle of a call to a string routine, and this has the effect (from a
legality point of view) of making the string operations atomic with
respect to tasking.  If you do something which the RM defines as
erroneous, you shouldn't be surprised to see erroneous behavior. (see
RM9X 9.10) Of course it would be nice for an implementation to do nice
things in such a case, but certainly losing track of garbage is not a
horrendous effect, especially since the way to avoid the erroneous
behavior is so simple.  (Do you really want two tasks asynchronously
doing reads and writes of the same string object?)


  
--

					Robert I. Eachus

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