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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=unavailable autolearn_force=no version=3.4.4
X-Received: by 10.36.122.149 with SMTP id a143mr810556itc.37.1485447521561;
        Thu, 26 Jan 2017 08:18:41 -0800 (PST)
X-Received: by 10.157.18.211 with SMTP id g77mr215620otg.14.1485447521523;
 Thu, 26 Jan 2017 08:18:41 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!feeder.eternal-september.org!news.glorb.com!r185no418392ita.0!news-out.google.com!15ni9215itm.0!nntp.google.com!r185no419133ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 26 Jan 2017 08:18:41 -0800 (PST)
In-Reply-To: <65f79e53-a468-4b77-8ee1-440c26a09371@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=2601:191:8303:2100:5985:2c17:9409:aa9c;
 posting-account=fdRd8woAAADTIlxCu9FgvDrUK4wPzvy3
NNTP-Posting-Host: 2601:191:8303:2100:5985:2c17:9409:aa9c
References: <65f79e53-a468-4b77-8ee1-440c26a09371@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8706d548-a9d5-48e5-aa6f-fd33013a2fd1@googlegroups.com>
Subject: Re: Question on type invariants
From: Robert Eachus <rieachus@comcast.net>
Injection-Date: Thu, 26 Jan 2017 16:18:41 +0000
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Xref: news.eternal-september.org comp.lang.ada:33180
Date: 2017-01-26T08:18:41-08:00
List-Id: <comp.lang.ada>

On Wednesday, January 25, 2017 at 3:38:53 AM UTC-5, reinkor wrote:
=20
> In principle I could mark A and S with a "last-modified-time-flag" so I c=
an update S when I find it necessary. This has similarities to unix "make".=
 Bad idea?

Responding to this point only, there are two decent ways to maintain last m=
odified values for A and S.  One way is to store timestamps. Update_S then =
compares the values of last_modified for A and S for equality.  If not equa=
l, copy the timestamp from A to S, and do the update work, otherwise exit i=
mmediately.  The potential problem here is that the timestamps may not be o=
f sufficient granularity.  The other approach is to use a counter, updated =
every time A is.  Again comparing for equality can be used to avoid the exc=
ess work.  In this case you need to worry about whether your counter is lar=
ge enough.  My tendency would be just to use a 64-bit integer.  But you may=
 not have atomic updates for 64-bit values, and S and A may be maintained b=
y different tasks.

For this case, there is a neat trick.  Use a smaller integer type for the c=
ounter.  When the S counter value is smaller than the A counter value, set =
both counters to zero, and do the S update.  This can all be done with a pr=
otected object, but with careful coding, it can be done with the counters b=
eing marked atomic.  Notice that it is possible that an update to A can occ=
ur while processing S.  You may need to use protected objects to insure tha=
t S_Update sees a consistent view of A.  However, it doesn't really matter =
whether the update to A is reflected in the new S, you may just have an add=
itional, unneeded update of S now or later.