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 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,4e5770c49b971630
X-Google-NewGroupId: yes
X-Google-Attributes: gida07f3367d7,domainid0,public,usenet
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!feeder.news-service.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!212.27.60.9.MISMATCH!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail
Date: Wed, 04 May 2011 17:25:43 +0200
From: Georg Bauhaus <rm.dash-bauhaus@futureapps.de>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US;
 rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: High-Integrity OO and controlled types
References: <d8204576-14ff-41a4-b850-ace9c15872d4@v8g2000yqb.googlegroups.com>
 <679e3217-98dd-43c1-86f6-2038a029c3ea@b19g2000yqg.googlegroups.com>
 <94f3a272-d071-4a74-bfbd-8f2b4c2347cf@m10g2000yqd.googlegroups.com>
 <cba1e286-d160-4f75-aebc-74f82ce78f30@26g2000yqa.googlegroups.com>
 <beefc106-01b0-4dec-ae7b-2ef41b1c7c78@b19g2000yqg.googlegroups.com>
 <f6e72476-0dca-4ab8-bfdf-94a0ddf7a7dc@j26g2000yqa.googlegroups.com>
 <4dbfe6cc$0$7664$9b4e6d93@newsspool1.arcor-online.net>
 <1in9ypl17vu1t$.1shivr91x8zw6.dlg@40tude.net>
 <4dc01dca$0$6885$9b4e6d93@newsspool2.arcor-online.net>
 <1ds39akl3dbii$.mlyj7piip5o3.dlg@40tude.net>
 <4dc112cf$0$6772$9b4e6d93@newsspool3.arcor-online.net>
 <gbwm0iuo4ed4$.1e5m2ye4kvqqj$.dlg@40tude.net>
 <4dc166bd$0$6973$9b4e6d93@newsspool4.arcor-online.net>
 <1ligthpgu6ogv$.dquevy2bn4tw$.dlg@40tude.net>
In-Reply-To: <1ligthpgu6ogv$.dquevy2bn4tw$.dlg@40tude.net>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Message-ID: <4dc16ff7$0$6985$9b4e6d93@newsspool4.arcor-online.net>
Organization: Arcor
NNTP-Posting-Date: 04 May 2011 17:25:43 CEST
NNTP-Posting-Host: 0a6a23ce.newsspool4.arcor-online.net
X-Trace: 
 DXC=JS=:9Hc3jboPKPPVf;4hUj4IUK<Cl32<a4Fo<]lROoRa8kF<OcfhCOkZRJjBmi>ei`nc\616M64>jLh>_cHTX3jmH^`Ia9RoH3d
X-Complaints-To: usenet-abuse@arcor.de
Xref: g2news1.google.com comp.lang.ada:19155
Date: 2011-05-04T17:25:43+02:00
List-Id: <comp.lang.ada>

On 04.05.11 17:01, Dmitry A. Kazakov wrote:

> This looks like the "checkpoint synchronization problem".

That's part of it.

>    http://rosettacode.org/wiki/Checkpoint_synchronization

Try adding pragma Profile (Ravenscar) there ;.)

> I would use a protected object to implement an array of events and
> distributing jobs among the worker tasks when they join or leave. I would
> likely place the array there. I would avoid polling.

The idea is to have two very busy tasks share an array
as efficiently as possible.

I'm trying to weigh all effects of rewriting the following
nest using the type-ized formalism that you have mentioned.

 procedure A is
   X : T;

   procedure B_Opt is
     type T1 is ...;
     Y : T1;
   begin
     Op(X, V);
     Op(Y, V);
   exception
     when ... =>
       Restore(X);  --?
       --  Y cleans up after itself
   end B_Opt;

 begin
   B_Opt;
   Op(X);
 end A;

Is there really little overhead when Restore is replaced
with some objects?