VSIPL 1.6 RTF Avatar
  1. OMG Issue

VSIPL16 — View's block reference-counting is inconsistent

  • Key: VSIPL16-22
  • Legacy Issue Number: 18220
  • Status: open  
  • Source: dpdx.net ( Brooks Moses)
  • Summary:

    The description of how block reference-counting works with
    view-allocated blocks is inconsistent.

    In 6.1.1. [block.alloc], it is stated that "For a block allocated by a
    view constructor, the effect of creation should include the effect of
    invoking increment_count."

    In 8.1 [view.view], however, the contrary requirement is given: "A
    constructor that does allocate its block must not invoke its block's
    increment_count member function."

    These do not appear to be consistent – or, at the very least, are very
    confusing. I suppose that the intended meaning is that, when a view
    allocates a block, the act of creating that block should increment the
    count, but that the view constructor should not otherwise increment the
    count. However, that's not at all clear from the text.

    Further, in 6.1.1, there is this note: "Note: For a block allocated by a
    view constructor, the number of increment_count invocations should meet
    or exceed the number of decrement_count invocations if the block is to
    be used. When the number of decrement_count invocations exceeds, not
    just equals, increment_count invocations, the block should be
    deallocated." This seems at first glance to be inconsistent with the
    definition of decrement_count, which states that the block will be
    deallocated when the value reaches zero, not goes below zero. It is
    only consistent if we assume that the phrase "the effect of invoking
    increment_count" does not include the effect of incrementing the number
    of times we consider increment_count to have been invoked!

    Much of this would be clarified if we simply explicitly stated, in the
    block requirements, that the "use count" should be set to one in the
    block constructor, rather than the "effect of calling increment_count"
    wording. Then we could omit the 6.1.1 paragraph 7 note entirely.

    (That points out a related omission: We do not actually specify the
    initial use-count value for the general case; for blocks that are not
    Dense and not created by a view constructor, a conforming implementation
    could initialize the use-count to infinity. Or three, just for
    perversity. This is probably not desirable.)

  • Reported: VSIPL++ 1.2 — Tue, 23 Oct 2012 04:00 GMT
  • Updated: Fri, 6 Mar 2015 20:57 GMT