Asynchronicity article - race conditions with Read_timer() ?

[Joel Sherrill <joel@OARcorp.com>]

Aaron J. Grier wrote:
> On Thu, Sep 09, 2004 at 08:57:28AM +1000, Andrew Sinclair wrote:
> 
>>I came across an article on the internet entitled Asynchronicity. Refer 
>>http://www.embedded.com/story/OEG20010615S0111
>>
>>It states
>>"The RTEMS real-time operating system provided by OAR Corp. 
>>(ftp://ftp.oarcorp.com/pub/rtems/releases/4.5.0/) is a nicely written, 
>>well-organized product with a lot of neat features. But the timer handling 
>>routines, at least for the Motorola 68302 processor, are flawed in a way 
>>that will fail infrequently, but possibly catastrophically."
>>
>>It speaks of race conditions with the Read_timer().
> 
> 
> it's an illustrative example of possible race conditions, but it's a
> straw man argument against actual RTEMS use.
> 
> the Read_timer() call is for calculating overhead of RTEMS calls in the
> c/src/tests/tmtests suite, and not for actual application use.
> 
> the rtems_timer_* calls provided by the timer manager use the clock tick
> routines provided by the board support package, and NOT the ones in
> timer/ .

Thanks for saving me the trouble of writing this.  I read this article
when it first came out and all I could think was that it was a great
explanation of a problem but not something to fret over in a Timer
Driver.  The timer driver is only used for benchmarking and only for
extremely small periods of times.  Even on the 16 Mhz 68020 and
16 Mha i386 boards RTEMS was first developed on, no test ran in
more than 30 milliseconds.  So the code meets its design requirements
if the timer can run for >= 30 milliseconds without overflowing and
generating an interrupt.

>>Is this a real issue? Has this been resolved?
> 
> 
> it's not an issue for production software, since none of the routines in
> c/src/lib/libbsp/m68k/gen68302/timer/ will be called.
> 
> the fix called out is easy enough to implement should race-free tmtests
> need to be fixed.

The timer is reset at the beginning of every test case.  If the counter
every overran, I would contend that you should change its settings so
it doesn't.

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985