EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Changes to records during asynch processing
From: Andrew Johnson <[email protected]>
To: [email protected]
Date: Tue, 02 Sep 2003 14:00:09 -0500
Peregrine M. McGehee wrote:

I concur with [Tim's] fundamental idea and suggest that the .RPRO field should contain a _list_ of structures to support multiple writes from clients during the period when PACT==1.

The naive implementation is a simple FIFO queue for write requests,
although in general this should be a priority queue.

I'm afraid this idea is a very long way from being as simple as it might seem, because of memory fragmentation issues. Marty has already posed the major issue - where are you going to save the values to put into the fields, especially as the data can be an array? To do that, you have to continually malloc and free memory, which currently only the Channel Access server does and then only when creating and destroying the tasks that maintain the network connection to a new client.


There are no calls to memory allocation routines inside the database runtime engine, precisely because continually doing that leads to memory fragmentation. We need EPICS to be capable of building systems that have uptimes of many months or more, and memory fragmentation problems would kill that existing capability.

Benjamin is right - we need to kill this gnat of a problem without blowing our own heads off in the process, which means a lot of thinking and testing of any radical changes. Marty does have a very good understanding of the issue, and is now proposing a relatively simple solution that reflects the caching nature of Channel Access (i.e. only the last value will be retained if the data target is busy). Anything more complex is not likely to be suitable for R3.14.x IMHO.

- Andrew
--
There are 10 types of people in the world:
Those who understand binary, and those who don't.


Replies:
Queuing/caching Peregrine M. McGehee
References:
Does DISP work for DB OUT links? Benjamin Franksen
Re: Does DISP work for DB OUT links? Marty Kraimer
Re: Does DISP work for DB OUT links? Benjamin Franksen
Re: Does DISP work for DB OUT links? Marty Kraimer
Re: Does DISP work for DB OUT links? Related question Benjamin Franksen
Re: Does DISP work for DB OUT links? Related question Marty Kraimer
Changes to records during asynch processing Benjamin Franksen
Re: Changes to records during asynch processing Marty Kraimer
Re: Changes to records during asynch processing Benjamin Franksen
Re: Changes to records during asynch processing Marty Kraimer
Re: Changes to records during asynch processing Tim Mooney
Re: Changes to records during asynch processing Peregrine M. McGehee

Navigate by Date:
Prev: Re: Changes to records during asynch processing Benjamin Franksen
Next: Re: [Fwd: Re: Does DISP work for DB OUT links? Related question] Marty Kraimer
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Changes to records during asynch processing Peregrine M. McGehee
Next: Queuing/caching Peregrine M. McGehee
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  <20032004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 10 Aug 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·