Home • About Us • A-Z Index • Search * Contact Us • Register • Login • Press • Shop

The Open Brand -- Problem Reporting and Interpretations System

Problem Report 1068 Details

Help Show help | Quick Search | Submit a Test Suite Support Request | Click here to view your privileges

This page provides all information on Problem Report 1068.

Report 1068 Actions

    Problem Report Number 1068
    Submitter's Classification Test Suite problem
    State Resolved
    Resolution Temporary Interpretation (TIN)
    Problem Resolution ID TIN.X.0064
    Raised 1970-01-01 08:00
    Updated 2003-03-13 08:00
    Published 1998-05-12 08:00
    Product Standard Internationalised System Calls and Libraries Extended V2 (UNIX 98)
    Certification Program The Open Brand certification program
    Test Suite VSRT version 5.0.1
    Test Identification rt.os/timers/timer_settime 9
    Specification System Interfaces and Headers Issue 5
    Location in Spec See Problem Text
    Problem Summary TIN4R.00005 This request contends the implementation is not obliged to report rounded numbers to the application.
    Problem Text

    Consider an implementation based on two time mechanisms: a high
    resolution time-of-day counter, capable of providing time information
    that resolves to less that 1 microsecond, and a periodic interrupt used
    to generate time-based events. Although the expected period of the
    interrupt timer (on the order of 1 to 10 milliseconds) is known in
    terms of increments of the time-of-day counter, it is not a fixed
    value. In this vendor's implementation, this variation is due to short
    term scaling of the counter in order to keep long-term synchronization
    with external time standards, but the following argument would also
    apply when the period interrupt is asynchronous from the time-of-day
    counter.

    Since the time-of-day counter provides such fine granularity, the
    vendor chooses to provide a return value from clock_getres() that
    represents the 1 microsecond resolution available through the
    clock_gettime() interface.

    The vendor then implements the timer_settime() expiration by comparing
    the time-of-day value with the requested it_value at each periodic
    interrupt. When the value exceeds the requested expiration time, the
    wakeup event for the process is generated. The time of the next event
    is computed by adding multiples of the it_interval until it exceeds the
    current time-of-day. Note that this computation does not involve
    either the resolution of the time-of-day counter or the interval of the
    periodic interrupt.

    The test case 9 has the following test assertion:

    If _POSIX_TIMERS is defined or the implementation supports the
    timer_settime() function as described in System Interfaces and
    Headers, Issue 5:

    A call to timer_settime() shall round up time values that are
    between two consecutive non-negative integer multiples of the
    resolution of the specified timer to the larger multiple of the
    resolution. Quantization errors shall not cause the timer to
    expire earlier than the rounded time value.

    On page 947 of XSH5, the following paragraph to the one cited above:

    If the argument ovalue is not NULL, the function
    timer_settime() stores, in the location referenced by ovalue, a
    value representing the previous amount of time before the timer
    would have expired or zero if the timer was disarmed, together
    with the previous timer reload value. The members of ovalue
    are subject to the resolution of the timer, and they are the
    same values that that would be returned by a timer_gettime()
    call at this point in time.

    The test case code interprets the standard to require that rounded time
    values be returned to the user when calls to timer_settime() and
    timer_gettime() are executed.

    The standard does require the implementation to perform rounding. This
    requirement appears in a paragraph specifying the relationship between
    the expiration of the timer and the underlying clock. In the described
    implementation, this rounding is implicit in using the much coarser
    resolution of the periodic timer to generate the wakeup event.

    The standard does not explicitly state that the internal rounding that
    may occur need be provided to the application. The phrase "The members
    of ovalue are subject to the resolution of the timer.." has an
    reasonable alternate interpretation for the implementation described
    above. This interpretation is that the implementation could, as it
    chooses, provide the rounded version of the input arguments that it may
    have computed in order to achieve compliance or, because it didn't need
    an explicit rounding to achieve compliance, it can simply return the
    exact it_interval from the original arguments. Under this
    interpretation, the implemantation has a choice of behavior, and the
    application has the onus of accepting both behaviors.
    Test Output
    10|1 /tset/rt.os/timers/timer_settime/T.timer_settime 08:35:26|TC Start,
    scenario ref 1-0, ICs: {9}
    15|1 3.1-lite 1|TCM Start
    400|1 9 1 08:35:26|IC Start
    200|1 9 08:35:26|TP Start
    520|1 9 00010989 1 1|With resolution of 0 seconds, 1000 nanoseconds
    520|1 9 00010989 1 2|Expected value 0 seconds, 1001 nanoseconds
    520|1 9 00010989 1 3|To be rounded up to 0 seconds, 2000 nanoseconds
    520|1 9 00010989 1 4|Received 0 seconds, 1001 nanoseconds
    520|1 9 00010989 1 5|With resolution of 0 seconds, 1000 nanoseconds
    520|1 9 00010989 1 6|Expected value 0 seconds, 999999001 nanoseconds
    520|1 9 00010989 1 7|To be rounded up to 1 seconds, 0 nanoseconds
    520|1 9 00010989 1 8|Received 0 seconds, 999999001 nanoseconds
    220|1 9 1 08:35:26|FAIL
    410|1 9 1 08:35:26|IC End

    Review Information

    Review Type TSMA Review
    Start Date null
    Completed null
    Status Complete
    Review Recommendation No Resolution Given
    Review Response
    PG4R.00008 and PG4R.00010 previously rejected this argument and we
    continue to consider this behavior non-conforming - the implementation
    does not have the option of returning inaccurate values from
    timer_settime or timer_getres. However as an alternative
    to this endless iteration we recommend a POSIX interpretation be
    generated and a Temporary Interpretation by issued by TOG.

    Review Type SA Review
    Start Date null
    Completed null
    Status Complete
    Review Resolution Temporary Interpretation (TIN)
    Review Conclusion
    A Temporary Interpretation is granted.

    Problem Reporting System Options:

     

    Back   

Contact the Certification Authority