Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
<== Date ==> <== Thread ==>

Subject: Re: Filling up epics queue / Multi threading on linux
From: Tim Mooney <mooney@aps.anl.gov>
To: Emmanuel Mayssat <emmanuel_mayssat@lynceantech.com>
Cc: Steven Hartman <hartman@fel.duke.edu>, EPICS tech-talk <tech-talk@aps.anl.gov>
Date: Thu, 05 Jan 2006 14:38:44 -0600


Emmanuel Mayssat wrote:

...
My follow up question is let's assume that I have a device with a scan
rate of .1 sec, but its processing take let's say 1 sec. The device may
or may not be programed as asynchronous.

If it's not asynchronous, then other records in the .1 second queue will not get processed while this device's record is waiting for a reply from the device. In this case, you life will suck, and eventually you'll change the device support to be asynchronous. Let's assume this has already happened.

I use redhat linux, or fedora ( not a real time OS )
let's assume that some records are trying to access the same bus ( but
the bus is most of the time busy ) at a scan rate of .1 sec.

In other words I am trying to do to many things at once ;-)

Now, what happens to the .1 sec epics queue ?
Does it fill up?
Does it crash the ioc?
What happens?

While the (asynchronous) record is busy, the .1 second scan task will check at 10 Hz to see if it can be processed, find out that it cannot be processed because it's already busy, and skip ahead to the next record in the scan queue.

The queue, by the way, is just a list of the names of records that must
be processed, not a list of processing requests.  The queue will not
get bigger or smaller unless more records go into or come out of the
scan group.

It seems that even if the records are not conflicting for the same
bus/resource, multi threading doesn't kick in the way I thought it
should. Can I have multi threading on a linux platform ?
If so, the epics queue should never "fill up", but my experience seems
to show otherwise.



-- Tim Mooney (mooney@aps.anl.gov) (630)252-5417 Beamline Controls & Data Acquisition Group Advanced Photon Source, Argonne National Lab.

References:
Building JCA1 John Faucett
Variable scan rate Emmanuel Mayssat
Re: Variable scan rate Steven Hartman
Re: Variable scan rate Emmanuel Mayssat
Re: Variable scan rate Steven Hartman
Filling up epics queue / Multi threading on linux Emmanuel Mayssat

Navigate by Date:
Prev: Filling up epics queue / Multi threading on linux Emmanuel Mayssat
Next: A couple of drvAsyn/devGpib questions LYNCH, Damien
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
Navigate by Thread:
Prev: Filling up epics queue / Multi threading on linux Emmanuel Mayssat
Next: Re: Building JCA1 Janet Anderson
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·