Am 02.03.2014 um 02:00 schrieb Jon Elson <[email protected]>:

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

RTAPI thread creation does support thread priorities. The way HAL uses this API 
is to create threads in descending order of priority. The HAL thread API also 
assumes threads are created in increasing thread period.

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.

- Michael
------------------------------------------------------------------------------
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

Reply via email to