Loading ...
Sorry, an error occurred while loading the content.

507Re: race condition in navigator

Expand Messages
  • ridgesoft
    Oct 8, 2011
    • 0 Attachment
      Hi,

      It looks like you have found a bug. The access of the mState variable is not protected in the run method so there is a potential race.

      Please try replacing the run method with the following version that adds synchronization.

      The source code for the class is available here: http://www.ridgesoft.com/articles/ridgewarriorii/RidgeWarriorIIPartIII.zip

      Please let us know if that fixes it.

      Regards,

      RidgeSoft Support

      /**
      * Run method for the navigation thread.
      */
      public void run() {
      try {
      while (true) {
      synchronized (this) {
      switch (mState) {
      case MOVE_TO:
      goToPoint();
      break;
      case GO:
      goHeading();
      break;
      case ROTATE:
      doRotate();
      break;
      default: // stopped
      break;
      }
      }
      Thread.sleep(mPeriod);
      }
      }
      catch (Throwable t) {
      t.printStackTrace();
      }
      }



      --- In intellibrain@yahoogroups.com, "graniterose2003" <graniterose2003@...> wrote:
      >
      > I have a wall-following class that uses the TVremote to pause/resume the robot. In the main thread a loop checks the IR sensors and uses nav.go(heading) to keep the bot near the wall. The TV remote is also checked each pass through the loop. The code to check the TVremote looks like the following
      >
      > private int chkRemote() {
      > int key = remote.read();
      > if (key == PAUSE) {
      > nav.stop();
      > while (remote.read() != PLAY) {
      > led4.toggle();
      > sleep(1000);
      > led4.toggle();
      > }
      > }
      > return key;
      > }
      >
      > Most of the time the pause/play works just fine. But every so often, after hitting PAUSE, the led will show we're in the PAUSE mode, but the motors are still running, despite having called nav.stop(); The remote won't stop the robot inside the toggle loop, but PLAY will give control back.
      >
      > The main loop is running at default priority, and the usual priorities are set for the encoders, screenmanager, and DifferentialDriveNavigator threads. So I'm not sure how the race condition occurs in the navigator thread. It seems that the navigator thread is about to call goHeading in the state switch loop when the main thread calls nav.stop(). The motors are stopped, but the navigator is resumed and calls goHeading so the motors are started again ....
      >
      > Of course, I can "fix" the race condition by putting a nav.stop() in the toggle loop of the remote checker ... but one wonders if there is a flaw revealed by the race condition ???
      >
    • Show all 4 messages in this topic