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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 21 Nov 2014 18:24:13 +0000 (UTC), Natasha Kerensikova wrote:

> 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/

Which is misleading. The result should have been an anonymous access. Then
it could not be copied without a conversion.

And there is a safe pattern (in Ada 2005) for handling references without
any access types and without implicit dereference.

>>> 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?

No, because Counter is not a helper type. A type is helper when needed due
to language reasons (deficiencies usually). When a type describes a problem
space entity like Counter does, it is not a helper.

>>>>> 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 reference count is a part of the object. When the object is gone, there
is no reference count.

Of course, you could add some levels of indirection to keep counters off
the objects, but then you would have serious problems, e.g. like Ada tasks
have when allocated and deallocated dynamically.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de