Re: Should weak counted reference be able to be strengthened?

[Natasha Kerensikova <lithiumcat@instinctive.eu>]

On 2014-11-21, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> 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