前面现已说过，uC/OS-II是一种根据优先级的可抢先的多使命内核。那么，它的多使命机制究竟怎样完成的呢?了解这些原理，能够协助咱们写出愈加强健的代码来。
首要咱们来看看为什么多使命机制能够完成?其实在单一CPU的情况下，是不存在真实的多使命机制的，存在的只要不同的使命轮番运用CPU，所以本质上仍是单使命的。但因为CPU履行速度非常快，加上使命切换非常频频并且切换的很快，所以咱们感觉如同有许多使命一起在运转相同。这便是所谓的多使命机制。
由上面的描绘，不难发现，要完成多使命机制，那么方针CPU有必要具有一种在运转期更改PC的途径，不然无法做到切换。不幸的使，直接设置PC指针，现在还没有哪个CPU支撑这样的指令。可是一般CPU都答应经过相似JMP，CALL这样的指令来直接的修正PC。咱们的多使命机制的完成也正是根据这个起点。事实上，咱们运用CALL指令或许软中止指令来修正PC，主要是软中止。
回想一下你在微机原理课程上学过的常识，当产生中止的时分，CPU保存当时的PC和状况寄存器的值到仓库里，然后将PC设置为中止服务程序的进口地址，再下来一个机器周期，就能够去履行中止服务程序了。履行结束之后，一般都是履行一条RETI指令，这条指令会把当时仓库里的值弹出康复到状况寄存器和PC里。这样，体系就会回到中止曾经的当地持续履行了。那么想象一下?假如再中止的时分，人为的更改了仓库里的值，那会产生什么?或许经过更改当时仓库指针的值，又会产生什么呢?假如更改是随意的，那么结果是无法意料的过错。因为咱们无法确认机器下一条会履行些什么指令，可是假如更改是方案好的，依照必定规矩的话，那么咱们就能够完成多使命机制。事实上，这便是现在简直一切的OS的中心部分。不过他们的完成不像这样简略算了。
下面，咱们来看看uC/OS-II再这方面是怎样处理的。在uC/OS-II里，每个使命都有一个使命操控块(Task Control Block)，这是一个比较复杂的数据结构。在使命操控快的偏移为0的当地，存储着一个指针，它记录了所属使命的专用仓库地址。事实上，再uC/OS-II内，每个使命都有自己的专用仓库，彼此之间不能侵略。这点要求程序员再他们的程序中确保。一般的做法是把他们声明成静态数组。并且要声明成OS_STK类型。当使命有了自己的仓库，那么就能够将每一个使命仓库再那里记录到前面谈到的使命操控快偏移为0的当地。今后每逢产生使命切换，体系必然会先进入一个中止，这一般是经过软中止或许时钟中止完成。然后体系会先把当时使命的仓库地址保存起来，仅接着康复要切换的使命的仓库地址。因为哪个使命的仓库里必定也存的是地址(还记得咱们前面说过的，每逢产生使命切换，体系必然会先进入一个中止，而一旦中止CPU就会把地址压入仓库)，这样，就达到了修正PC为下一个使命的地址的意图。
