我發現在許多機器上有用的一件事是一個簡單的堆棧切換器。我實際上沒有為PIC寫一個，但是我希望如果兩個/所有線程總共使用31個或更少的堆棧級別，則該方法在PIC18上會很好用。在8051上，主要例程是：
_taskswitch：xch a，SP xch a，_altSP xch a，SP ret
在PIC上，我忘記了堆棧指針的名稱，但是例程類似於：
_taskswitch：movlb _altSP >> 8 movf _altSP，w，b movff _STKPTR，altSP movwf _STKPTR，c return
程序，調用task2（）例程，該例程用備用堆棧的地址加載altSP（對於PIC18Fxx，16可能會很好地工作）並運行task2循環；這個慣例絕不能返回，否則事情將死於痛苦的死亡。相反，只要它希望對主要任務產生控制權，就應該調用_taskswitch。然後，只要主要任務要屈服於次要任務，就應調用_taskswitch。通常，會有一些可愛的小例程，例如：
void delay_t1（unsigned short val）{do taskswitch（）; while（（無符號短] [millisecond_clock-val）> 0xFF00）; } 請注意，任務切換器無法執行任何“等待條件”操作；它所支持的只是一次旋轉等待。另一方面，任務切換是如此之快，以至於在另一個任務正在等待計時器到期時嘗試taskswitch（）將切換到另一個任務，檢查計時器並比典型的任務切換器更快地切換回去將確定不需要執行任務切換。
請注意，協作式多任務處理有一些局限性，但是在不可變項被暫時干擾的情況下，它避免了使用大量鎖定和其他與互斥鎖有關的代碼的需求。可以快速重建。
（編輯）：關於自動變量的一些警告，例如：
- 如果兩個線程都調用了使用任務切換的例程，則通常有必要編譯該例程的兩個副本（可能是＃兩次包含相同的源文件，並使用不同的#define語句）。任何給定的源文件要么只包含一個線程的代碼，要么包含將被編譯兩次的代碼（每個線程一次），因此我可以使用“ #define delay（x）delay_t1（x）”之類的宏，或者#define delay（x）delay_tx（x）”取決於我正在使用的線程。
- 我相信無法“看到”正在調用的函數的PIC編譯器將假定該函數可能會破壞所有函數CPU寄存器，從而避免了在任務切換例程中保存任何寄存器的需求（與搶先式多任務處理相比，這是個不錯的好處），任何考慮為其他CPU使用類似任務切換器的人都需要了解所使用的寄存器約定。假設存在足夠的堆棧空間，在任務切換之前彈出並在之後彈出它們是一種輕鬆的方法來處理事務。 ol>
協作式多任務處理不能使人們完全擺脫鎖定等問題，但這確實確實大大簡化了工作。在具有壓縮垃圾收集器的搶占式RTOS中例如，r必須允許固定對象。使用協作式切換器時，如果代碼假設GC對象可以在tasktask（）調用時隨時移動，則不必這樣做。不必擔心固定對象的緊湊型收集器可能比簡單的收集器簡單得多。