Experimental Physics and
Industrial Control System

"Hill, Jeff" <[email protected]> · Fri, 8 Jun 2012 15:54:49 +0000

> I agree with Kay, that we have two different scenarios here and as a
> result we need two different APIs.

As I recall, in the current API, periodicity is determined by the return 
value from the timer expire function.

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Andrew Johnson
> Sent: Friday, June 08, 2012 9:50 AM
> To: [email protected]
> Subject: Re: epicsTimer and rounding
> 
> Hi All,
> 
> I agree with Kay, that we have two different scenarios here and as a
> result we
> need two different APIs.  I also agree with Eric and Ralph that the basic
> epicsThreadSleep() should follow the other implementations and *never*
> return
> earlier than the requested time period.  For example:
> 
>    nanosleep()  suspends the execution of the calling thread until either
>    at least the time specified in *req has elapsed, ...
> 
>    The usleep() function suspends execution of the calling process for (at
>    least) usec microseconds.  The sleep may be lengthened slightly by any
>    system activity or by the time spent processing the call or by the
>    granularity of system timers.
> 
> I have no problem with the idea of adding another routine that tries to
> maintain a long-term processing period.  However the scan threads do not
> use
> epicsThreadSleep() for this anyway, they call epicsEventWaitWithTimeout()
> because they need to be able to stop immediately when the IOC gets shut
> down,
> so this API also needs to accept an epicsEventId and to be able to tell
> the
> caller when it returns whether it's because of the timer or the event.
> 
> BTW, the CA client API should also provide a version of ca_pend_event()
> that
> takes an epicsEventId for similar almost-immediate shutdown purposes.
> 
> - Andrew
> 
> On 2012-06-08 Kasemir, Kay wrote:
> > I think Ralph's example of how 'sleep' is used is correct.
> > Must sleep at least as long as requested.
> >
> > What Jeff describes is a periodic timer.
> >
> > The Java Timer class nicely offers both, allowing to
> > a) schedule a task after some delay, with at least that delay
> > b) schedule a periodic task, where the period between invocations might
> be
> > 'squeezed' to achieve statistical correctness in the long run
> >
> >
> > These are different scenarios, and one epicsThreadSleep() can't do both.
> > The name epicsThreadSleep suggests to me that it's meant to be used for
> > the 'sleep', not for scheduling a periodic task.
> > That would require a different API like
> >
> > epicsThreadPeriodic(...)
> 
> --
> Never interrupt your enemy when he is making a mistake.
> -- Napoleon Bonaparte

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System