标签: 后台

Shell后台程序的管理 运行：  ，  %n 查看：jobs 停止：ctrl+z、ctrl+c 调前后台：fg  %n，  bg %n fg、bg、jobs、、nohup、ctrl+z、ctrl+c 命令 一、 加在一个命令的最后，可以把这个命令放到后台执行，如 watch -n 10 sh test. sh #每10s在后台执行一次test.sh脚本 二、ctrl + z 可以将一个正在前台执行的命令放到后台，并且处于暂停状态。 三、jobs 查看当前有多少在后台运行的命令 jobs -l选项可显示所有任务的PID，jobs的状态可以是running, stopped, Terminated。但是如果任务被终止了（kill），shell 从当前的shell环境已知的列表中删除任务的进程标识。 四、fg 将后台中的命令调至 前台 继续运行。如果后台中有多个命令，可以用fg %jobnumber（是命令编号，不是进程号）将选中的命令调出。 五、bg 将一个在后台暂停的命令，变成在 后台 继续执行。如果后台中有多个命令，可以用bg %jobnumber将选中的命令调出。 六、kill 法子1：通过jobs命令查看job号（假设为num），然后执行kill %num 法子2：通过ps命令查看job的进程号（PID，假设为pid），然后执行kill pid 前台进程的终止：Ctrl+c 七、 nohup 如果让程序始终在后台执行，即使关闭当前的终端也执行（之前的做不到），这时候需要nohup。该命令可以在你退出帐户/关闭终端之后继续运行相应的进程。关闭中断后，在另一个终端jobs已经无法看到后台跑得程序了，此时利用ps（进程查看命令） ps -aux | grep " test.sh " #a:显示所有程序 u:以用户为主的格式来显示 x:显示所有程序，不以终端机来区分  

背景任务的几种常见调度方式   我们喜欢RTOS，因为它足够简单；我们讨厌RTOS，因为它足够复杂。从“裸奔”到RTOS，首先意味着工程师们要去适应这些“新”东西，更要命的是要去给BOSS证明这些东西的可靠性——这是一个足够漫长的过程。在如今RTOS飞舞的时代，我们依然一路“裸奔”。呃，严重跑题了~~我不想说RTOS，我要说的是“裸奔”下的几种“风骚走位”——调度方式。   相对于RTOS，“裸奔”属于“前后台”框架。形象地说，后台就是那些在main()的超级循环里面的执行的函数集合；前台就是那些在ISR中执行的函数集合。其中，前台程序通常是对实时性能要求较为严格的任务，通常也是系统的核心任务。因此，后台程序就被称为“背景任务”。   下面讲讲几种背景任务的调度方式： l  方式1——非周期连续执行 这种方式应该是任何MCU初学者都会用到的，如下: 遥想当年瞎捣鼓51单片机时，全身上下只知道写个main()，硬生生在里面写了个电子日历=。= 本着“尽快跑”的简单实惠原则，方式1实现了一个闭环，非常适合应用于那些足够低端的MCU。（当然也不要指望这种情况下跑大量的实时code）   l  方式2——周期执行 相对于方式1，方式2强调了执行的“周期”实现。意味着设计者希望这些代码可以按照固定周期执行。如下： 方式2应用场合更为广泛一些。需要注意的是：即使前台任务足够短小，也只有首个任务A是较为实时的，后续任务都要受到前一个任务的执行时间影响，从而变得更加不实时——这是固有的缺陷。还有，如果多个任务的周期存在倍数关系，那么将会造成CPU负荷不均衡——即“忙就忙死，闲就闲死”现象。 另外还可以看出这些背景任务的执行周期是相同的（假设各任务的执行时间固定），那么我们可以说这些任务具有统一的速率。但是，如果我们希望不同任务有不同的速率呢？请看方式3.   l  方式3——周期多速率执行 这里多速率，指的就是不同任务具有不同的执行周期。周期越短的任务通常是被认为优先级越高的任务。如下： 如上图所示，类似（A-B1-C1-D1）组成了一个小环，若干个这样的小环组成一个大环。 假设节拍timeout表示1ms，那么各任务的执行周期如下： 任务 执行周期 (ms) 优先级 A 1 最高 B1 2   高 B2 2 C1 3   中 C2 3 C3 3 D1 4     低 D2 4 D3 4 D4 4     对比方式2，方式3显然的一个好处就是可以实现CPU负荷相对均衡。但是可以看出，方式3同样存在方式2中所说缺陷：即使前台任务足够短小，也只有首个任务A是较为实时的，后续任务都要受到前一个任务的执行时间影响，从而变得更加不实时。   如何尽量确保背景任务的实时性 ： 作为背景任务，自然不能指望他们拥有与前台任务一样的实时性能。但是也总不能落后太多吧 _ 下面的分析是基于前台任务的运行时间为常数。 （1）对于方式2，显然，只要在同一个环内，任务A~F的执行时间之和（包括前台任务占用的时间）小于timeout周期，即可相对保证背景任务的实时性能。 （2）对于方式3，只要在同一个 小环 内，任务A~D的执行时间之和（包括前台任务占用的时间）小于timeout周期，即可相对保证背景任务的实时性能。   结语 不管是跑RTOS还是“裸奔”，对系统的时序分析都是至关重要的，其分析深度往往体现了工程师对软件整体的把握程度。个人经验认为，“裸奔”足以应付大多数的单片机系统设计；至于RTOS嘛，要么就不用，要么就用最好的——包括人和产品。