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 15:00:12 +0000 (UTC), Natasha Kerensikova wrote:
>
>>    type Accessor (Data : not null access constant T) is limited record
>>       Parent : Strong_Reference;
>>    end record;
>
> Why do you need accessors? For Ada's crazy implicit dereference?

Not for implicit dereference, last time I checked my GNAT FSF didn't
handle it well.

Rather for the reasons explained in
http://www.adacore.com/adaanswers/gems/gem-107-preventing-deallocation-for-reference-counted-types/

>> However I agree that the strong reference inside
>> Accessor is indeed always on the stack, and guaranteed to never escape
>> from the Accessor object.
>
> Helper types is bad design.

I wasn't aware of that.

But then what about:

   type Counter is range 0 .. 640_000;  --  that ought to be enough for anybody

isn't that also a bad-design helper type?

>>>> 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.
>
> You cannot implement them without that. A weak reference must be
> invalidated when the object disappear. Thus some kind of notification must
> be there anyway.

In the example in the innermost quote, there is no direct notification,
in that there is no way to run arbitrary code when the referred object
disappear. However the information about object disappearance is
accessible to the weak reference: whenever the strong reference count is
zero, the referred object cannot be accessed. You could consider it at
as asynchronous notification, but that's still useless e.g. to clean-up
a cache entry or a signal handler (unless some periodic task goes
through the list of weak references to explicitly check whether they are
still valid).


Natasha