Программирование LEGO NXT роботов на языке NXC - Параллельные задачи

Автор: Daniele Benedettelli

Перевод: © Ботов Антон aka =DeaD=, 2009

Эксклюзивно для www.roboforum.ru
копирование на другие ресурсы и публикация перевода
без разрешения его автора запрещены

Параллельные задачи

As has been indicated before, tasks in NXC are executed simultaneously, or in parallel as people usually say. This is extremely useful. In enables you to watch sensors in one task while another task moves the robot around, and yet another task plays some music. But parallel tasks can also cause problems. One task can interfere with another.

Неправильная программа

Consider the following program. Here one task drives the robot around in squares (like we did so often before) and the second task checks for the touch sensor. When the sensor is touched, it moves a bit backwards, and makes a 90-degree turn. task check_sensors() { while (true) { if (SENSOR_1 == 1) { OnRev(OUT_AC, 75); Wait(500); OnFwd(OUT_A, 75); Wait(850); OnFwd(OUT_C, 75); } } } task submain() { while (true) { OnFwd(OUT_AC, 75); Wait(1000); OnRev(OUT_C, 75); Wait(500); } } task main() { SetSensor(IN_1,SENSOR_TOUCH); Precedes(check_sensors, submain); } This probably looks like a perfectly valid program. But if you execute it you will most likely find some unexpected behavior. Try the following: Make the robot touch something while it is turning. It will start going back, but immediately moves forwards again, hitting the obstacle. The reason for this is that the tasks may interfere. The following is happening. The robot is turning right, that is, the first task is in its second sleep statement. Now the robot hits the sensor. It start going backwards, but at that very moment, the main task is ready with sleeping and moves the robot forwards again; into the obstacle. The second task is sleeping at this moment so it won't notice the collision. This is clearly not the behavior we would like to see. The problem is that, while the second task is sleeping we did not realize that the first task was still running, and that its actions interfere with the actions of the second task.

Критические секции и "мьютекс"-переменные

One way of solving this problem is to make sure that at any moment only one task is driving the robot. This was the approach we took in Chapter VI. Let me repeat the program here.

mutex moveMutex; task move_square() { while (true) { Acquire(moveMutex); OnFwd(OUT_AC, 75); Wait(1000); OnRev(OUT_C, 75); Wait(850); Release(moveMutex); } } task check_sensors() { while (true) { if (SENSOR_1 == 1) { Acquire(moveMutex); OnRev(OUT_AC, 75); Wait(500); OnFwd(OUT_A, 75); Wait(850); Release(moveMutex); } } } task main() { SetSensor(IN_1,SENSOR_TOUCH); Precedes(check_sensors, move_square); } The crux is that both the check_sensors and move_square tasks can control motors only if no other task is using them: this is done using the Acquire statement that waits for the moveMutex mutual exclusion variable to be released before using motors. The Acquire command counterpart is the Release command, that frees the mutex variable so other tasks can use the critical resource, motors in our case. The code inside the acquirerelease scope is called critical region: critical means that shared resources are used. In this way tasks cannot interfere with each other.

Использование семафоров

There is a hand-made alternative to mutex variables that is the explicit implementation of the Acquire and Release commands. A standard technique to solve this problem is to use a variable to indicate which task is in control of the motors. The other tasks are not allowed to drive the motors until the first task indicates, using the variable, that it is ready. Such a variable is often called a semaphore. Let sem be such a semaphore (same as mutex). We assume that a value of 0 indicates that no task is steering the motors (resource is free). Now, whenever a task wants to do something with the motors it executes the following commands: until (sem == 0); sem = 1; //Acquire(sem); // Do something with the motors // critical region sem = 0; //Release(sem);

So we first wait till nobody needs the motors. Then we claim the control by setting sem to 1. Now we can control the motors. When we are done we set sem back to 0. Here you find the program above, implemented using a semaphore. When the touch sensor touches something, the semaphore is set and the backup procedure is performed. During this procedure the task move_square must wait. At the moment the back-up is ready, the semaphore is set to 0 and move_square can continue. int sem; task move_square() { while (true) { until (sem == 0); sem = 1; OnFwd(OUT_AC, 75); sem = 0; Wait(1000); until (sem == 0); sem = 1; OnRev(OUT_C, 75); sem = 0; Wait(850); } } task submain() { SetSensor(IN_1, SENSOR_TOUCH); while (true) { if (SENSOR_1 == 1) { until (sem == 0); sem = 1; OnRev(OUT_AC, 75); Wait(500); OnFwd(OUT_A, 75); Wait(850); sem = 0; } } } task main() { sem = 0; Precedes(move_square, submain); } You could argue that it is not necessary in move_square to set the semaphore to 1 and back to 0. Still this is useful. The reason is that the OnFwd() command is in fact two commands (see Chapter VIII). You don't want this command sequence to be interrupted by the other task. Semaphores are very useful and, when you are writing complicated programs with parallel tasks, they are almost always required. (There is still a slight chance they might fail. Try to figure out why.)

Подводим итоги

In this chapter we studied some of the problems that can occur when you use different tasks. Always be very careful for side effects. Much unexpected behavior is due to this. We saw two different ways of solving such problems. The first solution stops and restarts tasks to make sure that only one critical task is running at every moment. The second approach uses semaphores to control the execution of tasks. This guarantees that at every moment only the critical part of one task is executed.