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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: High-Integrity OO and controlled types Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <679e3217-98dd-43c1-86f6-2038a029c3ea@b19g2000yqg.googlegroups.com> <94f3a272-d071-4a74-bfbd-8f2b4c2347cf@m10g2000yqd.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> <4dc166bd$0$6973$9b4e6d93@newsspool4.arcor-online.net> Date: Wed, 4 May 2011 17:01:36 +0200 Message-ID: <1ligthpgu6ogv$.dquevy2bn4tw$.dlg@40tude.net> NNTP-Posting-Date: 04 May 2011 17:01:36 CEST NNTP-Posting-Host: 2db2e808.newsspool3.arcor-online.net X-Trace: DXC=@o1kb0:63d0gP]QSEBQ^d4McF=Q^Z^V384Fo<]lROoR18kF7enW;^6ZC`4\`mfM[68DC3;RCKCf[5>A4 X-Complaints-To: usenet-abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:19154 Date: 2011-05-04T17:01:36+02:00 List-Id: On Wed, 04 May 2011 16:46:21 +0200, Georg Bauhaus wrote: > On 04.05.11 11:28, Dmitry A. Kazakov wrote: > >> This does not read as a complete description. In what sense are the parts >> of the array shared? If sharing means only independent use of the parts, >> then what sense has the array as an object in this design? Independently >> used parts must be local to their users. Now, if there is something else >> behind this, i.e. that parts are sometimes used independently and sometimes >> together, then too little is said about the mechanisms used for the latter, >> and most intricate part of design. >> >>> This sounds like one could design types that >>> do(!) just this as part of their finalization. But it does >>> seem like an awful lot of overhead, and is essentially >>> a type that is-a procedure. >> >> You see that as an overhead only because the picture is incomplete. Once >> you fill the gaps, you will see how "exit action" firs there. That would >> definitely involve additional objects, e.g. controlled "handles" of which >> finalization would deal with "exit" and other operations would serve >> interlocking etc. > > A simple example (full source linked, but may not be > necessary); the intention is for it to be fairly low > level data manipulation. It is not nice, and could be > generalized in several ways, I think. If there is > justification for doing so. > > Array `Central` is manipulated by two tasks A and B. > When these have finished filling `Central`, the env task > computes the final result by counting certain values in `Central`. > Communication uses simple variables and visibility. > > The task B is sensitive to a special piece of input > and will restart its work from the beginning when > the input testing function raises Junk_Signal. This looks like the "checkpoint synchronization problem". http://rosettacode.org/wiki/Checkpoint_synchronization 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de