Good Concurrency vs. Bad Concurrency

Heres a quick good-design/bad-design example to illustrate how bad code can undermine a good RTOS. Assume that the function task_BLINKER() in Listing B.2 is a task in some RTOS-based application. This tasks job is very simple: wake up every second and toggle the state of the LED. The LED is adjusted and immediately the GoToSleep() system call is invoked. This task does just what it has to do, then blocks. Now look at the alternative function shown in Listing B.3.

Listing B.3: BLINKER_BAD()

 void task_BLINKER_BAD(void) {     while(1)     {         int timeout;         Turn_On_Led();         for(timeout=0;timeout<500000;timeout++);         Turn_Off_Led();         for(timeout=0;timeout<500000;timeout++);     } } 

 

If the time-out loop takes one second, the approach shown in Listing B.3 might seem like an adequate alternative. Unfortunately, however, Listing B.3 is far from adequate. Aside from the inaccuracy of the loops timing, Listing B.3 doesnt consider the fact that there are other tasks in the system. Because it does not issue any blocking system call, it uses as much of the CPU as the OS lets it have. Under certain circumstances this poor design might still end up working, but it is still a poor design because it is not taking advantage of the resources provided by the RTOS.

In many cases, Listing B.3 wont work at all. Assume that for some reason it is extremely important that this LED blink consistently. To assure timely execution, the task is likely to be set up to run at a high priority. If that is the case, preemption wont even help other tasks gain the CPU, because preemption only causes a task switch if the currently running task is running at a lower priority than some other task that is in the ready-to-run state. The point is that the RTOS cannot overcome a poor design! The developer still must write clean, well-informed code.