Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
<== Date ==> <== Thread ==>

Subject: Re: epicsTimer and rounding
From: Andrew Johnson <anj@aps.anl.gov>
To: core-talk@aps.anl.gov
Date: Fri, 8 Jun 2012 10:49:40 -0500
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

Replies:
RE: epicsTimer and rounding Hill, Jeff
References:
Re: epicsTimer and rounding Kasemir, Kay

Navigate by Date:
Prev: RE: epicsTimer and rounding Hill, Jeff
Next: RE: epicsTimer and rounding Hill, Jeff
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
Navigate by Thread:
Prev: Re: epicsTimer and rounding Kasemir, Kay
Next: RE: epicsTimer and rounding Hill, Jeff
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  <20122013  2014  2015  2016  2017  2018  2019  2020 
ANJ, 26 Nov 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·