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/04
Message-ID: <EACHUS.96Nov4182340@spectre.mitre.org>#1/1
X-Deja-AN: 194428430
references: <325BC3B3.41C6@hso.link.com>
 <EACHUS.96Nov1103759@spectre.mitre.org>
organization: The Mitre Corp., Bedford, MA.
newsgroups: comp.lang.ada
Date: 1996-11-04T00:00:00+00:00
List-Id: <comp.lang.ada>


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

  > Running under an operating system on a uniprocessor there clearly
  > must be a method of yielding to the lock-holder.  In a preemptive
  > scheduling environment this is automatic (although a yielding call
  > is more polite).  In a non-preemptive scheduling environment,
  > a simple call to yield the processor should suffice, and that
  > still leaves the overhead as approximately a memory read and
  > test.

   Not to pick on Larry--or anyone participating in this
discussion--but I am really confused.  Since all of the possible
modifications of Bounded_Strings must be done (legally) through a few
calls in the package, and Ada rules are really very clear in this
area, the Bounded_Strings package doesn't have to maintain any locks.

   It is the case that if you want to have a program which has
multiple tasks which reference the same bounded string, and one of
them does an update, then you have to have a synchronization point
before the next reference.

   Now as long as there are no synchronization points in the string
ops, you don't have a problem.  You can even allow for the case where
an allocation or free can be an external synchronization point.  The
only problem is transitive updates:

   Task 1:                     Task 2:

     Create string A;
     Create B = A; 
     Synch with task 2;          Synch with task 1;
     Modify B;                   Create string C = A;

     If you pay attention to the order of operations--and you have
atomic memory increment and decrement instruction--this works fine.
On systems where "cheap" synchronization operations are other than the
test and set model or counting semaphores, you may be limited to at
most two strings sharing the same text.  A better alternative would be
to put the creating task id in the heap object and only allow sharing
between strings created by the same task.  (It turns out not to be a
problem if a task goes away an a new task takes its identity.)

     So my proposal would be to write the code calling 'PRED and 'SUCC
on a volatile count field, and provide the current body on machines
which can't honor the pragma Volatile.  Oops!  One last merry little
detail.  Make the count type unsigned full word size so that you don't
get pessimistic code to deal with overflow.  (Yes, on some machines it
might be possible to have Unsigned'LAST + 1 pointers to the same
string object without overflowing memory, but I'm not going to worry
about it.)

--

					Robert I. Eachus

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