Asynchronicity article - race conditions with Read_timer() ?

[Chris Johns]

Andrew Sinclair wrote:
> I came across an article on the internet entitled Asynchronicity. Refer 
> http://www.embedded.com/story/OEG20010615S0111
> 

This article is from 2001 and an interesting read. The code sample used 
in the analysis provides an interesting example to work with for the 
purpose of the exercise. The code is simple to add no overhead when 
timing RTEMS performance.

> 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."
> 

The Read_timer function is used for the timing tests and is not used by 
the core of RTEMS or any of APIs. To state this could "possibly 
catastrophically" effect things is a over stating things a little.

  [ checked with '$ grep -R Read_timer rtems' ]

Given the timer tests tend to run for short periods of time and should 
be run a few times to get results I do not see this as a problem.

> It speaks of race conditions with the Read_timer().
> 
> Is this a real issue? Has this been resolved?

The author never submitted a patch that I know of.

> I tried looking through the mailing lists by seaching for "Asynchronicity", 
> but unfortunately the search engine appears to hang.

Simpler searches did not.

-- 
  Chris Johns