## 2 Hybrid Real-Time Scheduler in the MIROS
### Implementation of the MIROS Hybrid Scheduler  
In this section, the implementation of the MIROS hybrid scheduler and the scheduler switch mechanisms are presented. _Implementation of MIROS event-driven scheduler:_ In most event-driven WSN OSes, the scheduling queue mechanism is used for the implementation of the event-driven scheduler. In these OSes, the generated events are buffered in the scheduling queue, and then extracted and dispatched one by one by the event scheduler, as seen in Figure 2a. The scheduling queue is needed as the event-generating speed can be quicker than the event-dispatching speed. The scheduling principle can be the First Input, First Output (FIFO) or priority-based; the latter one supports real-time performance better. Figure 1: Hybrid scheduling structure in the MIROS. MIROS event-driven scheduler is typical in that only the non-RT tasks need to be schedule by it. Thus, the real-time performance is not a critical design factor, and the flag-polling mechanism other than the scheduling queue mechanism is used to schedule the events. In Figure 2b, the structure of the MIROS event-driven scheduling is depicted. Every non-RT task in the MIROS has one-bit flag. Once a task is activated, the related task's flag will be set. The event scheduler will poll the flags in loop. If a flag is found to be set, the related task will be executed. Task flags have the priorities that are statically assigned offline. The flags with the higher priorities will be polled in advance, thus the corresponded tasks can be executed earlier. If no flags are set, the sleeping directive will be executed, and then the node will fall asleep to conserve the energy. Compared with the scheduling queue mechanism, this flag-polling mechanism is less flexible as the scheduling sequence is fixed, but it is more efficient and more suitable for the non-RT task scheduling in the MIROS. _Implementation of MIROS multithreaded scheduler:_ Thread management is a key topic for the implementation of the multithreaded scheduler. It is essential as the number of the threads in the multithreaded OS can be large, e.g., in the uCOS the thread number can be as large as 64 or even 256. To schedule these threads efficiently, a sound thread management mechanism is needed. Currently in the uCOS and the mantisOS, the \"\(8\times 8\)\" lookup table [12] and the multilevel thread queues [7] are used respectively for the purpose of managing the threads efficiently. MIROS is different from the pure multithreaded OSes (uCOS, mantisOS, _etc._) in that only the RT tasks need to be executed by threads, thus the thread number is small and no complicated thread management mechanism is needed. As a result, a simple single-link queue is used for the thread management. In this queue, all the MIROS threads are queued in the order of their priorities (from highest priority to the lowest priority). The next thread to be scheduled can then be determined quickly by finding the first active thread in this thread queue. _Scheduler switch in MIROS:_ In MIROS, two kinds of switches exist. One is the _thread switch_ which occurs within the multithreaded scheduling system, and the other is the _scheduler switch_ which occurs between the event-driven scheduler and the multithreaded scheduler. In order to make the switching process efficient and easily managed, the event-driven scheduler in the MIROS is also implemented as a thread, named the \"_common_thread._\" The _run_ function of this _common_thread_ is to execute the MIROS event-driven scheduler. By doing this, the MIROS hybrid scheduling can be managed as the  
Figure 2: Event-driven scheduling structure. (**a**) General event-driven scheduling structure. (**b**) MIROS event-driven scheduling structure. pure multithreaded scheduling: (1) If all the RT threads are inactive, the next thread to be scheduled will be the _common_thread_. In this case, the OS will switch to the event-driven scheduling model, and all the non-RT tasks will be scheduled one by one.