Re: Bugs in 3.14.5

[Eric Norum <norume@aps.anl.gov>]

Kate Feng wrote:

> 2)  A patch is needed in RTEMS for all the
> 3.14.x/src/libCom/osi/os/RTEMS/epicsThread.c files mostly
> because a clock tick is required to support the functionality
> of  rtems_task_wait_after().
>
> The patch example for the 3.14.5 :
> diff  epicsThread.c epicsThread.c.orig

It's a little easier to see what you are proposing if you use the diff -c or 
-u options to provide some context for the changes.

> 58c58
> < static int initialized=0;
> ---
>
> > static int initialized;

I don't see how this makes any difference.  If your static variables aren't 
getting initialized to 0 there must be something wrong with the board-support 
package startup code.

> 385c385
> <         delay = 1;
> ---
>
> >        delay = 0;

I think that the existing behaviour matches the semantics described in the 
application developer's guide.  Here's the code in question:
============================================================
void
epicsThreadSleep (double seconds)
{
    rtems_status_code sc;
    rtems_interval delay;
    extern double rtemsTicksPerSecond_double;

    if (seconds <= 0.0) {
        delay = 0;
    }
    else {
        delay = seconds * rtemsTicksPerSecond_double;
        if (delay == 0)
            delay++;
    }
    sc = rtems_task_wake_after (delay);
    if(sc != RTEMS_SUCCESSFUL)
        errlogPrintf("epicsThreadSleep: %s\n", rtems_status_text (sc));
}
=============================================================
The documentation for epicsThreadSleep says, ".... If delay is <= 0 then a 
delay of 0 is requested of the underlying architecture.  What happens is 
architecture-dependent but often allows other threads of the same priority to 
run."   This is in fact what happens on RTEMS -- rtems_task_wake_after(0) 
causes a "yield to other tasks at the same priority".

--
Eric Norum                                 norume@aps.anl.gov
Advanced Photon Source                     Phone: (630) 252-4793
Argonne National Laboratory