On Sat, Dec 15, 2012, at 04:22 AM, Michael Haberler wrote:

> 
> I do not think this will be helpful at this point - this is a problem with 
> the HAL/RTAPI thread specification, or rather the lack thereof being precise 
> in an aspect which might or might not matter, but likely does
> 
> at the very least the code comment about rate monotonic scheduling and what 
> the implementation actually does dont agree AFAICT
> 


It has been a long time since I was really involved in
this, but I believe the initial intent was that the following
would be true:

1) slow thread periods would be an integer multiple of the
fastest thread period - if the requested periods don't meet
that requirement, they will be adjusted until they do.

2) If the slow thread period is 10x the fast period, then the
fast thread will run 10 +/- 1 times between each run of the
slow thread.

3) slow threads would never interrupt faster threads

Some of these things (in particular #3) were trivial to guarantee
back in the days of single-processor computers (SMP was very
new when this stuff was being defined).

In particular, I think #2 is a quite reasonable requirement.  If
a "100uS" thread is running 20 times between executions of
a "1mS" thread, and then sometime later it is running only
once or twice, that is simply wrong.  Even on a simulator
or virtual machine where neither 100uS nor 1mS is guaranteed,
the rule that 100uS runs 10 times while 1mS runs once should
be observed.

#1 is derived from the fact that in a real-time system, the
main time base is usually a programmable timer that is
generating interrupts.  There is often only one such timer
available.  It is programmed to interrupt at the fastest 
thread rate.  On every interrupt, the fastest thread is
dispatched.  If there is a slower thread with N times the
period, it is dispatched every N interrupts.


Regards,

John Kasunich

PS:  to Michael and others involved in this stuff:  I am very
happy to see you guys moving things to the next level.  I
wish I could take a bigger role, but my life has gotten rather
busy and I haven't done any real work on LinuxCNC in years.
But I really appreciate what you guys are doing!


------------------------------------------------------------------------------
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers

Reply via email to