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.66.161.40 with SMTP id xp8mr773178pab.39.1378981390162; Thu, 12 Sep 2013 03:23:10 -0700 (PDT) X-Received: by 10.49.99.37 with SMTP id en5mr49452qeb.8.1378981390085; Thu, 12 Sep 2013 03:23:10 -0700 (PDT) Path: border1.nntp.dca3.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!y3no18746389pbx.0!news-out.google.com!z6ni46734pbu.0!nntp.google.com!y3no18746387pbx.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 12 Sep 2013 03:23:09 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=20.132.64.141; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy NNTP-Posting-Host: 20.132.64.141 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Reference counting and idempotent finalize From: sbelmont700@gmail.com Injection-Date: Thu, 12 Sep 2013 10:23:10 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Original-Bytes: 2542 Xref: number.nntp.dca.giganews.com comp.lang.ada:183347 Date: 2013-09-12T03:23:09-07:00 List-Id: Suppose there are two shared pointers around, implying a reference count of= two. One of the references is finalized because it goes out of scope, and= the count decreases to one. Then finalize is "mysteriously" called on the= first reference a second time, which decreases the count to zero, and deal= locates the object. When you access the still-existing first reference, th= e data is gone and you get an exception. However, if you do this: if not Self.Is_Finalized then Release (Self.Access_Value);=20 Self.Is_Finalized :=3D true; end if; Then the second finalization does nothing and everything is fine. The 'mysterious' finalization comes from one of two places. First, if the = "Finalize" procedure is overriden in the public part, a client could explic= itly call it whenever they want, and a second 'normal' finalization would b= e called when it goes out of scope. =20 The second problem is if the executing task is aborted during an assignment= . If you do x :=3D y, then first you Finalize x, then copy y into x, and t= hen Adjust the new value of x. If someone aborts this task after the first= finalize starts but before the adjust starts, then the first finalize will= complete, the task will be aborted, and then x will be finalized again whe= n all the local objects are finalized. -sb