Changeset 77b0a73 in rtems


Ignore:
Timestamp:
03/07/06 22:10:35 (18 years ago)
Author:
Joel Sherrill <joel.sherrill@…>
Branches:
4.10, 4.11, 4.8, 4.9, 5, master
Children:
360d9da
Parents:
d5ed9e1
Message:

2006-03-07 Steven Johnson <sjohnson@…>

PR 850/rtems

  • score/src/watchdogtickle.c: A Watchdog (used to timeout an event) with a delay of 1 sometimes does not seem to timeout. The problem occurs, because for whatever reason when the watchdog tickle function executes, the watchdog->delta_interval is 0. it is then decremented before being tested, becomes huge and so doesnt time out. It is thought there is a race condition where the watchdog->delta_interval is calculated by reference to a head (also with a delay of 1). But before it can be added after the head, the head is removed, so the new head now has a delay of 0.
Location:
cpukit
Files:
2 edited

Legend:

Unmodified
Added
Removed
  • cpukit/ChangeLog

    rd5ed9e1 r77b0a73  
     12006-03-07      Steven Johnson <sjohnson@sakuraindustries.com>
     2
     3        PR 850/rtems
     4        * score/src/watchdogtickle.c: A Watchdog (used to timeout an event)
     5        with a delay of 1 sometimes does not seem to timeout.  The problem
     6        occurs, because for whatever reason when the watchdog tickle function
     7        executes, the watchdog->delta_interval is 0. it is then decremented
     8        before being tested, becomes huge and so doesnt time out.  It is
     9        thought there is a race condition where the watchdog->delta_interval
     10        is calculated by reference to a head (also with a delay of 1). But
     11        before it can be added after the head, the head is removed, so the
     12        new head now has a delay of 0.
     13
    1142006-03-07      Thomas Doerfler <Thomas.Doerfler@embedded-brains.de>
    215
  • cpukit/score/src/watchdogtickle.c

    rd5ed9e1 r77b0a73  
    5454
    5555  the_watchdog = _Watchdog_First( header );
    56   the_watchdog->delta_interval--;
    57   if ( the_watchdog->delta_interval != 0 )
    58     goto leave;
     56 
     57  /*
     58   * For some reason, on rare occasions the_watchdog->delta_interval
     59   * of the head of the watchdog chain is 0.  Before this test was
     60   * added, on these occasions an event (which usually was supposed
     61   * to have a timeout of 1 tick would have a delta_interval of 0, which
     62   * would be decremented to 0xFFFFFFFF by the unprotected
     63   * "the_watchdog->delta_interval--;" operation.
     64   * This would mean the event would not timeout, and also the chain would
     65   * be blocked, because a timeout with a very high number would be at the
     66   * head, rather than at the end.
     67   * The test "if (the_watchdog->delta_interval != 0)"
     68   * here prevents this from occuring.
     69   *
     70   * We were not able to categorically identify the situation that causes
     71   * this, but proved it to be true empirically.  So this check causes
     72   * correct behaviour in this circumstance.
     73   *
     74   * The belief is that a race condition exists whereby an event at the head
     75   * of the chain is removed (by a pending ISR or higher priority task)
     76   * during the _ISR_Flash( level ); in _Watchdog_Insert, but the watchdog
     77   * to be inserted has already had its delta_interval adjusted to 0, and
     78   * so is added to the head of the chain with a delta_interval of 0. 
     79   *
     80   * Steven Johnson - 12/2005 (gcc-3.2.3 -O3 on powerpc)
     81   */
     82  if (the_watchdog->delta_interval != 0) {
     83    the_watchdog->delta_interval--;
     84    if ( the_watchdog->delta_interval != 0 )
     85      goto leave;
     86  }     
    5987
    6088  do {
Note: See TracChangeset for help on using the changeset viewer.