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

Автор: Daniele Benedettelli

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

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

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

Как показывалось ранее, задачи в NXC выполняются одновременно, или как обычно говорят - параллельно. Это очень удобно. Такая возможность позволяет вам следить за датчиками в одной задаче, пока вторая задача управляет движением робота, а, скажем, третья задача играет какую-нибудь музыку. Но параллельные задачи могут создавать проблем. Одна задача может начать мешать другой.

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

Разберем следующую программу. В ней одна задача управляет движением робота по квадратам (как мы часто уже делали раньше), а другая задача проверяет датчик касания, когда датчик нажат, она отводит робота немного назад и делает поворот на 90 градусов.

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);
}

Вероятно программа выглядит как совершенно правильная, но если вы попробуете загрузить её в робота вы скорее всего обнаружите некоторое необычное его поведение. Попробуйте следующее, чтобы убедиться в этом: сделайте так, чтобы робот задел что-то бампером при повороте. Он начнет отъезжать назад, но немедленно снова начнет двигаться вперед, снова ударяясь о препятствие. Причина этого в том, что задачи начинают пересекаться. А происходит вот что. Робот едет в повороте и ударяется об препятствие. Он начинает отъезжать назад, но в этот момент главная задача (submain) завершает ожидание конца разворота и даёт команду ехать прямо на препятствие, игнорируя тот факт, что сейчас выполняется маневр отъезда от него. Вторая задача в это время находится в состоянии ожидания и даже не сможет обнаружить столкновение. Это точно не то поведение робота, которое мы хотели бы видеть. Проблема заключается в том, что пока вторая задача ждёт мы забыли, что первая задача продолжает работу и её действия начинают мешать работе задаче избегания препятствий.

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

Один из способов решения этой проблемы это введение механизма, гарантирующего, что только одна задача в данный момент работает с двигателями робота. Такой подход мы уже применяли в главе 6. Давайте посмотрим на эту программу еще раз.

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);
}

Загвоздка здесь в том, что обе задачи (check_sensors и move_square) контролируют моторы только если другая задача не использует их в данный момент. Это делается с помощью команд Acquire, которые ждут, чтобы "мьютекс"-переменная moveMutex стала свободной, перед тем как начать работать с моторами, после чего команда блокирует эту переменую и передаёт управление следующей команде. Команда Acquire всегда используется на пару с командой Release, которая сообщает системе, что "мьютекс"-переменная освободилась, и теперь другие задачи могут использовать соответствующий общий ресурс, в нашем случае - двигатели робота. Кусок программы внутри пары Acquire - Release называется критической областью программы, в том смысле, что используются общие ресурсы. Это гарантирует что в таких областях задачи не будут конфликтовать друг с другом по объявленным общим ресурсам.

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

Существует возможность собрать самому альтернативу "мьютекс"-переменым, являющуюся явной реализацией команд Acquire и Release.

Стандартный способ решить эту программу - объявить переменную, которая будет указывать, какая задача контроллирует двигатели. Другие задачи не должны использовать двигатели, пока первая задача не объявит их свободными. Такая переменная часто называется семафором. Пусть sem это такой семафор (это то же самое по сути, что и "мьютекс"). Мы будем считать, что значение 0 показывает, что двигатели свободны. Теперь, если задача хочет использовать моторы - она должна выполнить следующие команды:

until (sem == 0);
sem = 1; //Acquire(sem);
// Чего-то делаем с моторами
// (Это критическая область программы)
sem = 0; //Release(sem);

Сначала мы ждем, пока моторы будут свободны, затем забираем этот ресурс себе, выставляя 1. Теперь мы управляем ими. Когда мы всё, что хотели, сделали - пишем в sem снова 0. Ниже можно увидеть программу, реализующую семафор. Когда обнаруживается нажатие датчика касания, семафор выставляется в 1 и выполняется процедура отката назад. Во время неё задача move_square обязана ждать. Когда откат выполнен - семафор выставляется снова в 0 и задача move_square может продолжить.

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);
}

Вы можете сказать, что не ясно зачем в задаче move_square мы выставляем семафор в 1 и обратно в 0. Но на самом деле это полезно. Причина в том, что команда OnFwd() на самом деле состоит из двух команд (см. главу 8). Если вы не хотите, чтобы эту пару команд прервала другая задача - нужно так же блокировать здесь доступ к устройству.

Семафоры очень полезны и, когда вы пишете достаточно сложные программы с параллельными задачами, они почти всегда будут вам нужны. (Кстати, существует некоторый небольшой шанс, что такой семафор может не сработать. Попробуйте разобраться, почему.)

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

В этой главе мы научились решать некоторые проблемы, которые могут возникнуть при параллельной работе нескольких задач. Всегда будьте внимательны к возможным побочным эффектам при такой работе. Очень много случаев незапланированной работы программ возникает при работе с параллельными задачами. Мы увидели два возможных пути решения таких проблем. Первый заключается в том, что задачи выполняются в критической своей области по очереди. Второй подход использует семафоры для управления порядком выполнения команд. Это гарантирует что только одна задача в каждый момент времени будет находиться в своей критической области связанной с соответствующим общим ресурсом.