EPICS Controls 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  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Filling up epics queue / Multi threading on linux
From: Emmanuel Mayssat <[email protected]>
To: Steven Hartman <[email protected]>
Cc: EPICS tech-talk <[email protected]>
Date: Thu, 05 Jan 2006 11:55:21 -0800
This brings up an interesting point.
Another interesting question I wanted to ask. 

[Read below]

> > 3/ Bus conflict
> > 	There are also bus conflict I want to minimize
> > 	(several devices on same gpib bus, etc. )
> 
> What is to prevent the overload or the bus conflict from occuring at the
> most critical time, i.e. when many things are changing and your scan rates
> are all at their maximum?

Nothing can prevent conflict, but you can minimize their number.
The way to resolve this is of course with callbacks.
There should be no critical time with gpib devices ;-) readback should
be assumed as asynchronous.
Changing scan rate will (theoretically) enable the system to converge
toward a stable state ( read below when too many callbacks/processing at
once) 

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.
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?

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.

Any idea?
 
-- 
Emmanuel Mayssat
Cell: 650/793-0626
Lyncean Technologies, Inc.
"See the invisible"


Replies:
Re: Filling up epics queue / Multi threading on linux Tim Mooney
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

Navigate by Date:
Prev: Re: Variable scan rate Steven Hartman
Next: Re: Filling up epics queue / Multi threading on linux Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Variable scan rate Steven Hartman
Next: Re: Filling up epics queue / Multi threading on linux Tim Mooney
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·