Embedded Robotics (Thomas Braunl, 2 ed, 2006)

5 Multitasking

task 1 : 1 task 1 : 2 tastask 2 : 1 task 2 : 2 task 2 :k 1: 3 task 1 : 4

...

But even worse, the task switching can occur in the middle of the system call that writes one character to the screen. This will have all sorts of strange effects on the display and can even lead to a task hanging, because its data area was corrupted.

So quite obviously, synchronization is required whenever two or more tasks are interacting or sharing resources. The corrected version of this preemptive example is shown in the following section, using a semaphore for synchronization.

Program 5.2: Preemptive multitasking – first try (incorrect)

1 #include "eyebot.h"

2 #define SSIZE 4096

3 struct tcb *task1, *task2;

4

5void mytask()

6{ int id, i;

7id = OSGetUID(0); /* read slave id no. */

8for (i=1; i<=100; i++)

9LCDPrintf("task %d : %d\n", id, i);

10OSKill(0); /* terminate thread */

11}

12

13int main()

14{ OSMTInit(PREEMPT); /* init multitasking */

15task1 = OSSpawn("t1", mytask, SSIZE, MIN_PRI, 1);

16task2 = OSSpawn("t2", mytask, SSIZE, MIN_PRI, 2);

17if(!task1 || !task2) OSPanic("spawn failed");

18

19OSReady(task1); /* set state of task1 to READY */

20OSReady(task2);

22OSReschedule(); /* switch to other task */

23/* -------------------------------------------------- */

24/* processing returns HERE, when no READY thread left */

25LCDPrintf("back to main");

26return 0;

27};

72

Synchronization

5.3 Synchronization

Here, we will concentrate on synchronization using semaphores. Semaphores are rather low-level synchronization tools and therefore especially useful for embedded controllers.

5.3.1 Semaphores

The concept of semaphores has been around for a long time and was formalized by Dijkstra as a model resembling railroad signals [Dijkstra 1965]. For further historic notes see also [Hoare 1974], [Brinch Hansen 1977], or the more recent collection [Brinch Hansen 2001].

A semaphore is a synchronization object that can be in either of two states: free or occupied. Each task can perform two different operations on a semaphore: lock or release. When a task locks a previously “free” semaphore, it will change the semaphore’s state to “occupied”. While this (the first) task can continue processing, any subsequent tasks trying to lock the now occupied semaphore will be blocked until the first task releases the semaphore. This will only momentarily change the semaphore’s state to free – the next waiting task will be unblocked and re-lock the semaphore.

In our implementation, semaphores are declared and initialized with a specified state as an integer value (0: blocked, t1: free). The following example defines a semaphore and initializes it to free:

struct sem my_sema; OSSemInit(&my_sema, 1);

The calls for locking and releasing a semaphore follow the traditional names coined by Dijkstra: P for locking (“pass”) and V for releasing (“leave”). The following example locks and releases a semaphore while executing an exclusive code block:

OSSemP(&my_sema);

/* exclusive block, for example write to screen */

OSSemV(&my_sema);

Of course all tasks sharing a particular resource or all tasks interacting have to behave using P and V in the way shown above. Missing a P operation can

73

5 Multitasking

result in a system crash as shown in the previous section. Missing a V operation will result in some or all tasks being blocked and never being released. If tasks share several resources, then one semaphore per resource has to be used, or tasks will be blocked unnecessarily.

Since the semaphores have been implemented using integer counter variables, they are actually “counting semaphores”. A counting semaphore initialized with, for example, value 3 allows to perform three subsequent non-block- ing P operations (decrementing the counter by three down to 0). Initializing a semaphore with value 3 is equivalent to initializing it with 0 and performing three subsequent V operations on it. A semaphore’s value can also go below zero, for example if it is initialized with value 1 and two tasks perform a P operation on it. The first P operation will be non-blocking, reducing the semaphore value to 0, while the second P operation will block the calling task and will set the semaphore value to –1.

In the simple examples shown here, we only use the semaphore values 0 (blocked) and 1 (free).

Program 5.3: Preemptive multitasking with synchronization

1 #include "eyebot.h"

2 #define SSIZE 4096

3struct tcb *task1, *task2;

4struct sem lcd;

5

6void mytask()

7{ int id, i;

8id = OSGetUID(0); /* read slave id no. */

9for (i=1; i<=100; i++)

10{ OSSemP(&lcd);

11LCDPrintf("task %d : %d\n", id, i);

12OSSemV(&lcd);

13}

14OSKill(0); /* terminate thread */

15}

16

17int main()

18{ OSMTInit(PREEMPT); /* init multitasking */

19 OSSemInit(&lcd,1); /* enable semaphore */

20task1 = OSSpawn("t1", mytask, SSIZE, MIN_PRI, 1);

21task2 = OSSpawn("t2", mytask, SSIZE, MIN_PRI, 2);

22if(!task1 || !task2) OSPanic("spawn failed");

23OSReady(task1); /* set state of task1 to READY */

24OSReady(task2);

26OSReschedule(); /* switch to other task */

27/* ---- proc. returns HERE, when no READY thread left */

28LCDPrintf("back to main");

29return 0;

30};

74

5 Multitasking

Program 5.4: Preemptive main

1#include "eyebot.h"

2#define SLAVES 3

3 #define SSIZE 8192

4struct tcb *slave_p[SLAVES], *master_p;

5struct sem sema[SLAVES];

6struct sem lcd;

7

8int main()

9{ int i;

10OSMTInit(PREEMPT); /* init multitasking */

11for (i=0; i<SLAVES; i++) OSSemInit(&sema[i],0);

12OSSemInit(&lcd,1); /* init semaphore */

13for (i=0; i<SLAVES; i++) {

14slave_p[i]= OSSpawn("slave-i",slave,SSIZE,MIN_PRI,i);

15if(!slave_p[i]) OSPanic("spawn for slave failed");

16}

17master_p = OSSpawn("master",master,SSIZE,MIN_PRI,10);

18if(!master_p) OSPanic("spawn for master failed");

19for (i=0; i<SLAVES; i++) OSReady(slave_p[i]);

20OSReady(master_p);

22OSReschedule(); /* start first task */

23/* -------------------------------------------------- */

24/* processing returns HERE, when no READY thread left */

25LCDPrintf("back to main\n");

26return 0;

27}

Program 5.5: Slave task

76

5 Multitasking

Each task can be in exactly one of three states (Figure 5.1):

•Ready

A task is ready to be executed and waiting for its turn.

•Running

A task is currently being executed.

•Blocked

A task is not ready for execution, for example because it is waiting for a semaphore.

Blocked

Figure 5.1: Task model

Each task is identified by a task control block that contains all required control data for a task. This includes the task’s start address, a task number, a stack start address and size, a text string associated with the task, and an integer priority.

Round robin Without the use of priorities, i.e. with all tasks being assigned the same priority as in our examples, task scheduling is performed in a “round-robin” fashion. For example, if a system has three “ready” tasks, t1, t2, t3, the execution order would be:

t1, t2, t3, t1, t2, t3, t1, t2, t3, ...

Indicating the “running” task in bold face and the “ready” waiting list in square brackets, this sequence looks like the following:

t1 [t2, t3] t2 [t3, t1] t3 [t1, t2]

...

Each task gets the same time slice duration, in RoBIOS 0.01 seconds. In other words, each task gets its fair share of processor time. If a task is blocked during its running phase and is later unblocked, it will re-enter the list as the last “ready” task, so the execution order may be changed. For example:

t1 (block t1) t2, t3, t2, t3 (unblock t1) t2, t1, t3, t2, t1, t3, ...

78

Scheduling

Using square brackets to denote the list of ready tasks and curly brackets for the list of all blocked processes, the scheduled tasks look as follows:

Whenever a task is put back into the “ready” list (either from running or from blocked), it will be put at the end of the list of all waiting tasks with the same priority. So if all tasks have the same priority, the new “ready” task will go to the end of the complete list.

Priorities The situation gets more complex if different priorities are involved. Tasks can be started with priorities 1 (lowest) to 8 (highest). The simplest priority model (not used in RoBIOS) is static priorities. In this model, a new “ready” task will follow after the last task with the same priority and before all tasks with a lower priority. Scheduling remains simple, since only a single waiting list has to be maintained. However, “starvation” of tasks can occur, as shown in the following example.

Starvation Assuming tasks tA and tB have the higher priority 2, and tasks ta and tb have the lower priority 1, then in the following sequence tasks ta and tb are being kept from executing (starvation), unless tA and tB are both blocked by some events.

79

5 Multitasking

The scheduler now simply selects the next task to be executed from the (non-empty) “ready” queue with the highest dynamic priority. If there are no eligible tasks left in any “ready” queue, the multitasking system terminates and continues with the calling main program. This model prevents starvation and still gives tasks with higher priorities more frequent time slices for execution. See the example below with three priorities, with static priorities shown on the right, dynamic priorities on the left. The highest dynamic priority after decrementing and the task to be selected for the next time slice are printed in bold type:

5.5 Interrupts and Timer-Activated Tasks

A different way of designing a concurrent application is to use interrupts, which can be triggered by external devices or by a built-in timer. Both are very important techniques; external interrupts can be used for reacting to external sensors, such as counting ticks from a shaft encoder, while timer interrupts can be used for implementing periodically repeating tasks with fixed time frame, such as motor control routines.

The event of an external interrupt signal will stop the currently executing task and instead execute a so-called “interrupt service routine” (ISR). As a

80