On Sat, Mar 1, 2014, at 09:32 PM, Charles Steinkuehler wrote: > On 3/1/2014 7:25 PM, Michael Haberler wrote: > > > > Keep in mind we are talking about a simulator (now called the 'posix > > thread style') issue. The question at hand does not apply to any of > > RTAI, Xenomai or RT-PREEMPT RT flavors. Also, none of the simulator > > configurations under configs/sim use more than one thread. > > Like I said...IMHO it doesn't seem worth breaking what could be a very > useful feature for multi-core systems just to match historical behavior > in a case where it doesn't really matter anyway. > > ...or am I missing something obvious? > > -- > Charles Steinkuehler > char...@steinkuehler.net
I think it does matter, at least unless/until someone does a detailed code review of existing components. 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. 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 jmkasun...@fastmail.fm ------------------------------------------------------------------------------ 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 Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
