基于双核处理器平台的数控系统数控软件架构设计

　　4.4 不可调度情况下的线程重分配

　　在表2所示情况下，线程无法合理调度，这时可以考虑减少这个核心上的实时线程数，多出的实时线程分配到另外一个核心Core0上。那么选择哪几个线程与Linux共享Core0呢?这里要重点考虑两个问题：一是线程的重要性和优先级，二是线程交互的情况。首先，应尽量保证最重要的线程在专用核心corel上运行，一般来说循环周期短、优先级高的线程相对比较重要，比如emcmotTask线程，因而不应该把该线程移到Core0上。其次，考虑线程交互情况，互相之间存在频繁数据通信的几个线程应该尽量放到同一个核心上，比如PLCThread和emcmotTask线程之间共享大量数据，则把这两个线程一起放在Corel上，而把TaskThread放到Core0上。这种情况下的线程安排如图4。

图4另外一种线程分配 

　　这样安排完之后还要再次进行测算，保证各核心上的实时线程满足调度要求。Core0上只有Task．Thread这一个实时线程，一定可以调度。而Corel上，U=0.7135<0.8284，满足可调度性条件，因而这种安排是合理的。

　　4.5 负载均衡

　　假设所有实时线程按照图3的方案分配到Corel上，对于表3所示的线程时间，计算出u=0.7265<0.7798，满足可调度性条件，但是该核心负载比较高；而core0上只有Linux，负载比较低。从负载均衡的角度考虑，可以把一些低优先级和实时性要求相对较低的实时线程(比如TaskThread)放到core0上，使两个核心上的负载更均衡一些。另外，如果各核心负载都比较低，并且缓存失效和线程调度等造成的时间消耗远小于实时线程运行时间的话，也可以考虑直接采用RTCore默认线程分配策略，即由调度器动态地在两个核心上调度线程运行，线程与核心没有固定的对应关系。

5 双核平台上的中断管理

　　在运行RTCore系统的双核平台上，中断管理比较灵活，用户可以根据需要对中断进行精细的控制，比如单独为每个中断设置处理器亲和性。设计实时数控系统时，要区分实时和非实时中断。实时中断是直接与数控系统相关的中断，必须马上予以处理；而其他的则是非实时中断，比如IDE接口、网卡和串口等占用的中断，不必马上处理。注册了实时中断后，每当产生这中断，处理器立即停止正在执行的任何实时和非实时代码，转而执行对应的实时中断处理程序；而如果产生的是非实时中断，则RTCore只是简单地做一个标记，表明产生了一个需要由Linux来处理的中断请求，等处理器在空闲时间运行Linux时，存在于Linux内核中的中断处理程序才真正处理这个请求。

　　一般情况下实时中断处理程序和数控实时线程之间存在着频繁的数据通信。这时可以使实时中断请求指向实时专用核心，而其他非实时中断则指向另外一个核心。这样做有一个前提，即实时中断处理不能导致实时线程过度延期。通常情况下中断处理时间远远小于应用程序运行时间，因而可以忽略其影响。但是如果实时中断频率比较高，处理时间又比较长，就必须考虑中断对实时线程的影响。通常外部中断的产生具有一定的随机性，在此可以进行一些简化，认为实时中断是一个周期性中断。这样就会有中断周期和周期内最大处理时间，可以把该中断处理程序看成一个周期性实时线程，然后采用RM算法判定其可调度性。比如表4的例子，U=0.495<0.7798，因此把该中断指向实时专用核心是可以的。

6 总结

　　设计基于双核处理器平台的数控软件架构时要考虑的问题主要包括缓存局部性、任务可调度性、负载均衡和中断管理。在线程分派方面，

　　(1)如果线程的实时性要求不高，线程调度等导致的延迟不会影响实时性的话，可以采用内核默认的自由调度方案。

　　(2)从性能和实时性方面考虑，可以直接把实时线程和非实时线程分派到不同核心上。

　　(3)经RM算法判定实时线程无法在一个核心上合理调度的话，取出若干个重要性和实时性要求较低的实时线程放到非实时线程所在核心上。

　　(4)在各核心上实时线程满足可调度性要求的前提下，从负载均衡方面考虑，也可以取出若干个重要性和实时性要求较低的实时线程放到非实时线程所在核心上。

　　在中断管理方面，要根据中断的实时性要求以及与实时线程的交互关系，把中断请求指向不同的核心。在实际应用中，要综合考虑线程的实时性要求、线程交互、调度器损耗和中断干扰等因素，结合本文提出的方法，对数控软件架构进行设计，以充分利用双核处理器平台的性能优势。