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=unavailable autolearn_force=no version=3.4.4 Path: border2.nntp.dca1.giganews.com!nntp.giganews.com!newspeer1.nac.net!newsfeed.xs4all.nl!newsfeed4a.news.xs4all.nl!xs4all!feeds.phibee-telecom.net!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Natasha Kerensikova Newsgroups: comp.lang.ada Subject: Re: Should weak counted reference be able to be strengthened? Date: Fri, 21 Nov 2014 15:00:12 +0000 (UTC) Organization: A noiseless patient Spider Message-ID: References: <7d9r3whe43z8$.1f2l3n5cz0zh0$.dlg@40tude.net> Injection-Date: Fri, 21 Nov 2014 15:00:12 +0000 (UTC) Injection-Info: mx02.eternal-september.org; posting-host="76a49b86bc3e16725b7cfca3d85cb4c8"; logging-data="12205"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18vqHHUDUd1mtrSctfnGuRv" User-Agent: slrn/1.0.1 (FreeBSD) Cancel-Lock: sha1:rHJcOlJPuLFHUvl2E9A3U8QlQSg= Xref: number.nntp.giganews.com comp.lang.ada:190910 Date: 2014-11-21T15:00:12+00:00 List-Id: On 2014-11-21, Dmitry A. Kazakov wrote: > On Fri, 21 Nov 2014 11:07:07 +0000 (UTC), Natasha Kerensikova wrote: > >> So my question is, now that I am considering extending my >> reference-counting system to include weak reference, do I really needed >> a public interface to build a strong reference from a weak one? > > Yes. Thanks. >> Or is it enough to have weak reference primitives that return Accessor >> and Mutator objects, thereby allowing safe access without allowing a >> weak reference to be promoted into a strong one? > > How this is supposed to work? The only safe referential object is a strong > reference. The strong reference is hidden in the accessor object. Consider for example the following specification fragments, where T is the formal type of the referred objects: type Accessor (Data : not null access constant T) is limited private; type Strong_Reference is tagged private; function Query (Ref : Strong_Reference) return Accessor; type Weak_Reference is tagged private; function Weaken (Parent : Strong_Reference'Class) return Weak_Reference; -- 'Class only because we are still in the same package function Query (Ref : Weak_Reference) return Accessor; private type Accessor (Data : not null access constant T) is limited record Parent : Strong_Reference; end record; The only way to actually reach a referred object is by dereferencing the access discriminant of an Accessor value. The strong reference inside Accessor objects ensure that the referred object will outlive the Accessor object. However in that example, there is no way for the client to obtain a strong reference from a weak one, since the one inside Accessor (that ensures safe access) is private. >> In all the use cases I can imagine, the weak reference is only used to >> access the referred object. I can't make up an example where a strong >> reference would be needed from only a weak one. Am I missing something? > > Yes. There are many cases when weak references are components of containers > or when weak references are used in composite objects which change their > content upon disappearance of the referenced object. I wasn't aware of such a possibility, that's probably the big thing I missed. In all the examples with which I came up, the owner of a weak reference doesn't need to distinguish between an empty reference that never held an object and an empty reference because the object has been released. >> The interesting point I see in forbidding such a "reference >> strengthening" is to prevent some cases circular strong references, >> which is the problem weak references are supposed to solve. > > When a weak reference is promoted to a strong one that occurs on a nested > context. Such strong references are allocated on the stack. Therefore there > is no any danger of getting circular dependencies unless the structure of > references in objects is already circular. In short, there is nothing to > worry about. Such strong references are not limited, and could be very well be copied to a permanent object. Or at least, strong references like the one in my spec example above. However I agree that the strong reference inside Accessor is indeed always on the stack, and guaranteed to never escape from the Accessor object. So to make it live longer, one would need to allocate an Accessor on the heap, which would be conspicuous. >> As a side note, I'm a bit surprised by how easy weak/strong reference >> seem to be: I think I would only need to store two counters instead of >> one, one for the strong references and one for all references, >> deallocating the object when the strong reference counter reaches >> zero, and freeing the counters when the total counter reaches zero -- as >> if each weak reference was a strong reference to the counters. Then it's >> only a matter of adding an atomic increase-if-not-zero to the strong >> reference counter to build accessors from weak references. >> Is there a subtle trap I'm missing? > > Weak references usually require a notification mechanism when the object > disappears. Thus you need a count and the head of the doubly-linked list of > the weak references pointing to the object. I'm still not completely figuring out how much usefulness is lost when the notification mechanism is not implemented. Honestly, weak references with notifications feel like too large a project for me. Even more complicated systems, like those you described in the following snipped paragraph, are also out of the question. There is only so much I feel comfortable to re-invent. So basically now, I'm wondering whether my poor limited weak references still have some use or whether I should be giving up entirely. As far as I can see, they are still useful as "backlinks", e.g. a parent object that has containers whose elements need a reference to the parent, though that's a bit limited... Thanks for your comments, Natasha