This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

timeout values "cyg_flag_timed_wait" <theorethic discussion>


Lately I checked to see what happens if I give an absolute time to
cyg_flag_timed_wait which is in the past.
In practice, a timeout is returned (which is of course a good thing).

While browsing the ecos code, I found the following code:

clock.cxx #148:
        // increment the counter, note that it is
        // allowed to wrap.
        counter += increment;
***

The defines:
    volatile cyg_tick_count counter;    // counter value
    cyg_tick_count      trigger;        // Absolute trigger time

    typedef cyg_uint64 cyg_tick_count_t;
    typedef unsigned cyg_halint64   cyg_uint64 ;
    #ifndef cyg_halint64
    # define cyg_halint64 long long
    #endif
***

In the alarm functions, which are used by cyg_flag_timed_wait, timeouts are
checked as follows:

            if( alarm->trigger <= counter )

This implies that if 'counter' wraps around, alarm->trigger will never get
called until next wrap around after say 5849 miljon year.
(10ms interval, increment counter = 1)
OK, I know this is a bit of a non isue, as the counter will never wrap around in
the lifetime of the hardware :)

1) should we change the comment  "increment the counter, note that it is allowed
to wrap." to something as "increment the counter, note that it is supposed to
never wrap in the lifetime of the software"

2) change the code
            if( alarm->trigger <= counter )
to
            cyg_tick_count difference = alarm->trigger - counter;
            if ( ((cyg_halint64) difference) <= 0 )

3) can we speed up the alarm lists by using unsigned long for cyg_tick_count on
some (slow) platforms? I guess it would work fine on my 66MHz arm processor.
This should then be a configuration option, as it does create a few limits:
alarms are not allowed to go far into the future (in the 10ms 1 increment case,
(2^31)/(100*60*60*24) = 248 days), the clock increment must always be 1, and the
increment rate should not be extreme high (10ms)).

Please don't take this discussion too seriously, as ecos works fine as it is
right now.

Eric



-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]