最近在做一个专案，里面有三十个设备要控制
因为三十个设备不能互相卡住，所以就开了三十个 thread
另外程式要有所展示，所以 main thread 也就是 ui thread
由 main thread 开出 30 个设备 thread, 那现在看到有 31 个了
CPU 的效率拨进来这支程式，假设是平均且 free run
那么每个 thread 都占用了 1/31 的 CPU 时间
我在每个 thread 做过一次判断后，都有 sleep(1)
这意思是每个设备，每秒都判断一次应该要做什么动作
这时 UI 变很卡了...
理想上每个 thread 遇到 sleep 指令，它就睡了
然后 CPU 时间会拨给剩下的 thread 去平均分享
如果每个设备的判断式都执行很快，那么在别的 thread 的 sleep 一秒内，就足以做完
当程式跑久以后，每个 thread 都有可能全速奔驰
只要它们别同时醒著
也许是我写的判断式效率不好，渐渐的感觉到程式变很卡
而把 sleep 加长有助于解决这个问题
其实我想分配每个 thread 的优先权了
一开始的想法便是利用 lock
首先产生一个 lock 当全域物件
30 个 thread 都引用它且互斥
with lock:
设备判断式
这样可使 30 个 thread 同时只能有一个执行
而我在设备判断式里，也只简单的把一个计数器加一
据以观察 30 个设备的执行机率平不平均
结果是非常不平均；但这样写是最简单的
我会担心，会不会运气不好，某设备经常不执行？
后来我想了一个法子，由我自己控制
我产生一个 list, 里面有所有 30 个设备 thread 的指标
只要某 thread 被执行，就把它移到 list 的最尾端
那么最前端就是没被执行到，我希望它执行的
用这个方法等于把 30 个 thread 串起来，因为同时只有一个在动
我等于就把它们变一个 thread (难道 thread group 就是在做这件事？）
我希望的是 30个设备 thread 总共占用 50% CPU 时间
而 main thread 占用另外的 50% CPU 时间；也就是平分～
这样会不会有什么问题呢？有没有更简单的想法呢？
觉得自己打造了不少轮子
而且这样似乎又违反了一开始的初衷（设备不要互相卡住）
因为我只要一个设备有 bug, 卡住不动
剩下 29 个设备会全部赔葬 XD
把话反过来说好了，一开始我就不想写 30 个 thread，我本来要用一个 thread 做完
举例来说，一个射击类电玩里，敌机可能有一百架
难道这电玩就用一百个 thread 来写？
当然是一个 thread 就很好写啊...
但因为我的开发出了点问题，老板就叫我快点改成 multi-thread
至少一个设备卡住也不影响其他设备
另外当初在学同步物件时，有个东西就搞不懂
好像有个叫 信号机 的物件，它不像 lock 是完全互斥
而是它可以允许一个量（比如同时有五个 thread pass，一个结束才能再唤醒一个）
我一直无法想像这东西用在哪，从没用过
难道就用在这？
比如，我 30 个设备会卡，但当初开发到一半时还很顺，大概可以容许 15 个设备
我就设 15 个设备的信号机，这样程式也不会卡，但也不是同时所有 thread 都在动
难道就是用在这？
但我还是会担心，允许 15 个设备，就有哪个设备不受照顾，睡死一方..
这种同步物件，有保证所有 thread 的机率尽量均等吗？
以上请教，谢谢