On 03/01/2014 02:51 PM, Charles Steinkuehler wrote: > Coming from the hardware world, I would argue that threads must be > assumed to operate in any order, and at any time, including fully > concurrently on a multi-core system. Well, then, I can see a problem in the case you have a thread with small CPU requirements that runs at 10 X the frequency as another thread with a longer CPU requirement. If the longer-running thread cannot be interrupted by the faster thread, you are guaranteed to have a serious latency problem. In the somewhat reverse case as Sebastian describes, if the longer-running less-frequent thread can interrupt the short-running more-frequent thread, it will definitely make latency of the faster thread worse, and seems a perverse way to do scheduling, at least from the LinuxCNC point of view. Now, the way these threads are scheduled, I don't think the scheduler is given any info on how long to expect the threads to take, so it is at a disadvantage. Also, I didn't think there was an explicit scheduling priority given, just that there was an implicit rule of RT-Linux and RTAI tha the faster thread would have the higher priority. The most flexible scheme would be where thread priority was explicitly given when the thread was started.
Jon ------------------------------------------------------------------------------ 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
