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.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD,
	FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!news.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Natasha Kerensikova <lithiumcat@gmail.com>
Newsgroups: comp.lang.ada
Subject: Re: Reference counting and idempotent finalize
Date: Thu, 12 Sep 2013 05:34:53 +0000 (UTC)
Organization: A noiseless patient Spider
Message-ID: <slrnl32kjd.1lme.lithiumcat@sigil.instinctive.eu>
References: <slrnl30ie3.1lme.lithiumcat@sigil.instinctive.eu>
 <5rbmj2y8ml2b$.e0ygtir1g3mt$.dlg@40tude.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Sep 2013 05:34:53 +0000 (UTC)
Injection-Info: mx05.eternal-september.org;
 posting-host="31d6bde745a337034b005384ef225743";
	logging-data="1917"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18GcasMBudl2Zlx7+0iluwk"
User-Agent: slrn/0.9.9p1 (FreeBSD)
Cancel-Lock: sha1:rOLYnrDoNglCuCs16VgqI9f9bz0=
Xref: news.eternal-september.org comp.lang.ada:17165
Date: 2013-09-12T05:34:53+00:00
List-Id: <comp.lang.ada>

On 2013-09-11, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> You could make an alternative version for debug scenario which keeps track
> of all changes of the reference count dumping them on errors. GNAT stack
> trace is handy for that. Do not trust reference counting, it is an endless
> source of many hideous errors even if the implementation of is correct.

Would you please elaborate on why reference counting shouldn't be
trusted? What dangers am I brazingly exposing myself to?

> Tracing for the latest exception when in Finalize (GNAT functionality) is
> extremely helpful as well, because upon error propagation you get a
> snowball of cascading exceptions hiding the original problem. Always kill
> any exceptions in Finalize and do an emergency tracing in the handler.
>
> Yet another version is likely needed for tasking, that is when the
> reference objects are used concurrently, so that the reference count is
> updated concurrently. You will need a protected object to handle increments
> and decrements and careful design preventing concurrent increments when the
> count reached 0.

All these refinements are way beyond the scope a basic roll-my-own
implementation. If I needed such complexity I wouldn't have tried to
implement it without having thoroughly checked that there is no suitable
implementation already available.

I have roughly the same heuristic for concurrent stuff and for proper
fault recovery as I have for cryptography: never try to code it at home
unless it really does not exist elsewhere yet.