DDS 1.0 NO IDEA Avatar
  1. OMG Issue

DDS — DDS ISSUE# 53] Refactor lifecycle state

  • Key: DDS-144
  • Legacy Issue Number: 6854
  • Status: closed  
  • Source: Real-Time Innovations ( Dr. Gerardo Pardo-Castellote, Ph.D.)
  • Summary:

    Ref-84 Lifecycle_state_refactor

    The precise interpretation and representation of the lifecycle and
    sample states in the specification is not clear.

    Figure 2-11 is not easy to interpret as it refers to "observable"
    lifecycles rather than representing some internal state that the
    application accesses.

    Several issues are left open such as

    Whether what happens if in the sample history of a single instance are
    new, modified, and deleted samples (i.e. the instance was disposed and
    then created again before the reader accessed it). An additional
    question is then whether the read/take will return samples belonging
    to multiple "generations" of the instance.

    How can an application determine that as a result of a single
    read/take operation multiple samples of the same instance appear. This
    may be important because the processing a new/modified sample may
    depend on the number of samples the application has for that instance.

    Also the representation of the instance_state as an enumeration:
    NEW/MODIFIED/DELETED/NO_WRITERS is not natural. If this represents the
    state of the instance, then the instance can be simultaneously
    MODIFIED and DELETED; it can be MODIFIED and have no writers,
    etc. That is logically these are not mutually exclusive

    **PROPOSAL**

    Change the description in section 2.1.2.5.1 and representation
    lifecycle as described below.

    Replace the lifecycle_state with the following two variables (flags)

    observation_lifecycle =

    {NEW, NOT_NEW}

    liveness_lifecycle =

    { ALIVE , DISPOSE_EXPLICIT, DISPOSED_NO_WRITERS }

    Define DISPOSED as the union (DISPOSED_EXPLICIT | DISPOSED_NO_WRITERS)

    The observation_lifecycle and liveness_lifecycle are independent. All
    combinations are possible. So the lifecycle may be simultaneously NEW
    & DISPOSED_EXPLICIT, NOT_NEW & ALIVE, etc.

    All the samples in the history of an instance have the same
    "lyfecycles" states. Each time a sample is received (or a loss of
    liveliness on a remote DataWriter is detected) the liveness_lifecycle
    may change. If it changes it changes for all samples belonging to the
    same instance.

    If an instance was DISPOSED (either DISPOSED_EXPLICIT or
    DISPOSED_NO_WRITERS) and a samplefor that instance is received, the
    liveness_lifecycle of the instance changes to ALIVE.

    If a sample is received for a DataWriter, indicating that the ser has
    called "dispose" for that instance then the liveness_lifecycle of the
    instance changes to DISPOSED_EXPLICIT.

    If the infrastructure detects the loss of liveness of a DataWriter for
    the instance and this is the only DataWriter writing the instance
    known to the reader then the liveness_lifecycle of the instance
    changes to DISPOSED_NO_WRITERS

    Each time the liveliness of an instance changes from ALIVE to
    DISPOSED_EXPLICIT an internal count maintained per instance
    (disposed_explicit_count) is incremented. Each time the liveliness of
    an instance changes from ALIVE to DISPOSED_NO_WRITERS an internal
    count maintained per instance (disposed_no_writers_count) is
    incremented.

    The observation_lifecycle and liveness_lifecycle as well as the
    disposed_explicit_count and disposed_no_writers_count appear in the
    SampleInfo returned when the application reads/takes samples. This
    counters are from the perpective of the DataReader and start at 0 when
    the liveness_lifecycle is NEW

    Each time the application reads or takes samples, all returned samples
    for any one instance have the same observation_lifecycle and
    liveness_lifecycle. They represents the "snapshot" of the
    corresponding values for the instance taken at the time the data is
    read or taken.

    The disposed_explicit_count and disposed_no_writers_count in
    SampleInfo are not the same. On all samples. They represent the number
    of lifecycles of each kind that the instance had gone through at the
    time the sample stored into the history queue. The application can use
    this to distinguish samples belonging to different generations. In
    addition the SampleInfo contains an additional filed. The
    "instance_rank" that specifies how many samples for the same instance
    follow in the sequence retuned as part of the read/take. This helps
    the application anticipate that more samples for the same instance
    follow. The last sample for the instance returned will always have a
    instance_rank==0

    In addition the SampleInfo contains an additional filed. The
    "generation_rank" that specifies the generation to which the sample
    belongs relative to the generations

    The observation_lifecycle, liveness_lifecycle, disposed_explicit_count
    and disposed_no_writers can be used as in the expressions used for the
    purposes of making a Query.

    Figure 2-11 should be updated to reflect the state-transitions
    described above.

    Both the read and take operations affect the
    observation_lifecycle. The first time the application reads/takes
    samples for an instance the observation_lifecycle will be NEW. After
    the observation_lifecycle will be NOT_NEW.

    Once the application reads/takes samples with the liveness_lifecycle
    DISPOSED (either EXPLICIT or NO_WRITERS), the observation_lifecycle is
    'reset' and if new samples are received for that instance the
    observation_lifecycle will be set to NEW again.

  • Reported: DDS 1.0b1 — Tue, 23 Dec 2003 05:00 GMT
  • Disposition: Resolved — DDS 1.0
  • Disposition Summary:

    see below

  • Updated: Fri, 6 Mar 2015 20:58 GMT