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: Benjamin Franksen <[email protected]>
To: [email protected]
Date: Tue, 02 Sep 2003 20:27:49 +0200
Marty Kraimer wrote:
> 
> Benjamin Franksen wrote:
> 
> > P.S. I have the impression that nowadays asynchronous processing is
> > rather the rule than the exception, with the wide adoption of field
> > busses. Here at BESSY more than half the records with hardware device
> > support use CAN bus and so are asynchronous.
> 
> GTACS, the precurser of EPICS, did not have the concept of asynchronous records.
> Device support had to be written so that it was synchronous. Asyn support was
> invented for gpib devices. Once it was available people found many uses for it.
> Sigh!!

I am not so sure we should shed tears over asynchronous processing as
such. Surely it makes all the runtime support stuff a lot more
complicated. OTOH, the trend in the computer world is going more and
more towards asynchronicity, just look at all the network stuff. Latest
example are devices directly supporting VXI-11. You simply cannot do
these things synchronously and still keep the database running at a
reasonable speed.

I agree with Tim that we should aim at making the asynchronous
processing semantics follow the synchronous one as closely as possible
(within the limits of practicability).

In the long run I'd even suggest to re-think the database link semantics
for asynchronous target records. The Asynchronous Soft Support module I
wrote can be viewed as a little step in this direction.

I also agree with Jeff that the discussion is about enhancing the core
runtime system (making it more complex) in order to simplify the things
for the user (=database designer, developer of record and device
supports). I also agree that we have to be very careful about creating
overhead. The more radical changes that were proposed surely need a lot
of thinking, testing and optimizing.

Ben

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

Navigate by Date:
Prev: Re: Changes to records during asynch processing Peregrine M. McGehee
Next: Re: Changes to records during asynch processing Andrew Johnson
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: Queuing/caching Peregrine M. McGehee
Next: vme watchdog timer john sinclair
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 ·