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: "Hill, Jeff" <johill@lanl.gov>
To: Andrew Johnson <anj@aps.anl.gov>, "core-talk@aps.anl.gov" <core-talk@aps.anl.gov>
Date: 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: core-talk-bounces@aps.anl.gov [mailto:core-talk-bounces@aps.anl.gov]
> On Behalf Of Andrew Johnson
> Sent: Friday, June 08, 2012 9:50 AM
> To: core-talk@aps.anl.gov
> 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


Replies:
Re: epicsTimer and rounding Andrew Johnson
References:
Re: epicsTimer and rounding Kasemir, Kay
Re: epicsTimer and rounding Andrew Johnson

Navigate by Date:
Prev: Re: epicsTimer and rounding Andrew Johnson
Next: Re: epicsTimer and rounding Eric Norum
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 Andrew Johnson
Next: Re: epicsTimer and rounding Andrew Johnson
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 ·