John,
Am 02.03.2014 um 15:21 schrieb John Kasunich <[email protected]>:
I think we are onto something pretty fundamental here.
> Most HAL components don't care. But some, like the software
> step generator and encoder counter, probably do. Each of
> those consists of two parts, one running in the fast thread
> that actually generates or counts pulses, and another in the
> slow thread that handles scaling and control.
>
> There are several variables that are used to communicate
> between the two parts.
can you confirm the issue you describe above is the following:
the problem is about passing _several scalar values between threads in an
atomic fashion_ (transactional, meaning - all of them updated, or none of them
updated as seen by the receiving thread).
Is this what you are talking about? I think that is a very important property,
and it is key to spell this out very clear. But a scheduling policy might not
be the only solution to this problem, and not necessarily the best.
Depending whether this is the case, we go from there.
- Michael
> The faster part was written assuming
> that those variables would not change during any single
> execution of the code. Allowing the slower thread to have a
> higher priority (and thus to interrupt) the faster thread would
> break that assumption.
>
> Also, as Jon pointed out, allowing the low frequency task
> to interrupt the high frequency one would really screw up
> latency. A typical LCNC configuration might have a 50uS
> base thread, with code that executes in about 20uS, and
> a 1mS servo thread, with code that executes in about 300uS.
>
> As currently defined, the 50uS base thread will interrupt the
> servo thread at least 6 times, and will generate pulses with
> the proper timing. If the priorities were flipped, the base
> thread would be blocked for 300uS, which is a huge latency
> hit.
>
> Rate monotonic scheduling was not done on a whim, it is
> the only way to do proper real-time control when several
> threads are running at different periods with different
> work-loads.
>
> I find it hard to believe that these new RTOS options don't
> offer a task priority mechanism. Even Linux user space
> tasks have priority (although it is rarely used on the desktop,
> most tasks have the same priority).
>
> Note that RTAPI/HAL doesn't rely on the OS supplying a
> rate monotonic scheduling method. The OS only needs
> to supply a task priority system. RTAPI/HAL sets the
> priorities when the threads are created, such that you get
> rate monotonic scheduling.
>
> Does posix really not provide a "thread priority" function?
> If it does, then we should simply assign realtime threads
> a priority that is higher than the default user thread
> priority.
>
> I don't think the lack of dual-thread sample configurations
> is relevant. Simulator mode should be capable of simulating
> ANY valid configuration, the only limitation being a lack
> of hard-real-time timing guarantees (and possibly lack of
> hardware drivers because of permissions).
>
>
> --
> John Kasunich
> [email protected]
>
> ------------------------------------------------------------------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
> Customize your own dashboards, set traffic alerts and generate reports.
> Network behavioral analysis & security monitoring. All-in-one tool.
> http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
> _______________________________________________
> Emc-developers mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/emc-developers
------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
