(1)例程中的公共和私有只是相当于事物关系上的公共体和个人体,而不是指访问的可见性.公共虽然总体重要,但每个个体的私事应该更重要,各扫门前雪.这也是回跳时尽量只处理最紧要的私事,当然如果必须要涉及公共逻辑的除外.

(2)例程中每次跳站和恢复的时候:最先检测到自己掉站事件的那个任务及时的for循环遍历通知和自己站号相同的任务(自己直接挨个遍历通知队友即第三层成员直接通知第三层成员):我检测到通讯挂了所以通知你们及时跳站,或者是我检测到通讯已经恢复了通知你们可以继续通讯了.这个for遍历通知事件虽然是可行的,但这种遍历通知应该可以省略,改为单个事件通知响应.而且约定好第二层公共私有数据的话也不必把#从读写错,#从超动时传递给其余的从站,而只需给第二层上级汇报即可(自己把掉站信息汇报上级,队友查询上级#掉站情况决定是否跳站).

(3)将例程中数据结构再增加一层抽象变成三层: 

第一层公共全局变量(所有站号共同需要用到的:时钟,波特率,校验码等变量)  

第二层公共私有变量(同一个站号私有子任务的公共变量:如#掉站情况(或8个字节甚至10个字节)/#从掉站数/#从写站数/#从读站数)   

第三层私有全局变量(每个私有任务自己的私有数据)

这样每个第三层的私有任务发生掉站或恢复事件后及时通知汇报并改变第二层里面相同站号的#掉站情况这个数据结构对应的Bool量位,就可以省去for循环事件通知,但逻辑上需要在第三层私有事件里联络第一层公共全局变量的#全局循计以及第二层公共私有全局#掉站情况:即每个私有任务检测到第二层的公共私有变量#掉站情况<>0就跳站,在从站规模小,基本无所谓多几次for循环开销,但规模大了,就值得适当增加空间复杂度:复杂数据构成和逻辑处理以达到降低时间复杂度的目的-----------本质是空间换时间,体现了时间和空间的辩证平衡.例程中30多个参数的排列顺序以及逻辑梯形图写法应该没有达到空间和时间的相对优越,只能是差不多.......

(4)Ch_Write变化才写或者检查写这个子程序的逻辑虽然大致没问题,但频繁的FOR循环也是可以改善的,可以结合#全局循计来针对单个检查写变化事件进行通知,即#从控触发==1且#从读写控==1时才去写检查一次且只检查判断当前#全局循计序号任务的这次变动;或者通过上游的逻辑程序(非通讯程序)来产生#从变才写通知事件并及时的传递到通讯程序的每个私有事件对应的变量中,比如暂定名#从变通知,但这样可能需要形成双向的闭环通知,而且这样做是否真的可以优化时序不是100%确定......

(5)结合以上,例程"错漏难免"是实实在在的,通过增加时序逻辑以及数据构成复杂度来减少时间复杂度在很多时候是必要的......

(6)指针的进化和退化很多时候也是必要的,即指针类型信息的丰富化和集约化,(64位8字节)在32位系统中进化丰富化指的是编程语言比如C#需要针对4字节指针增加丰富许多额外的必要信息如哈希值,表头指针等等才能完整的描述一个"类";退化集约化指的是有时需要通过委托,里氏转换,子类代父类,子类代接口等机制来直接进行"穿越性"的相互通知和操作......

(7)一个班级的每个成员拥有相对确定,不太容易频繁动态变化的"地址"(微信号/家庭地址/手机/电话等)之外,也会有很多附加的动态的信息来完善和描述每个成员的状态,这就类似指针的进化来优化丰富成员的动态成长和发展过程;当遇到重要的事件需要通知联络的时候可能还是需要用到指针的退化进而准确的投递到一个地址(微信号/家庭地址/手机/电话等),进而产生及时的互动响应.宏内核,微内核.....