EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: double buffered waveformRecord
From: Andrew Johnson <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Tue, 22 Jan 2013 19:39:07 -0600 (CST)
Hi Michael,

On Jan 22, 2013, at 6:19 PM, Michael Davidsaver <[email protected]> wrote:

> I've posted another iteration.  The changes have actually gotten much shorter.
> 
> The first patch changes dbAccess.c and arr.c to save the original value of DBADDR::pfield before calling get_array_info, then restore it immediately after.
> 
> http://bazaar.launchpad.net/~epics-core/epics-base/array-opt/revision/12397

I haven't tried this, but it looks much better.

> The second patch changes waveformRecord.c to allow the safe replacement of BPTR whenever the record is locked.  No special allocation, or pointer tricks, are needed.
> 
> http://bazaar.launchpad.net/~epics-core/epics-base/array-opt/revision/12398

You can simplify it even more; use &prec->val instead of &prec->bptr as the field identifier to db_post_event() because cvt_dbaddr() doesn't need to change the paddr->pfield value at all then, it's already pointing to the val field on entry.

Is this completely backwards compatible with existing waveform device support? I get the impression that it should be, but I haven't checked. If so even the waveform record changes would be acceptable to merge into 3.15. I would like some documentation on how to do double-buffering in device support though.

BTW, have you looked at the aai record type in 3.15 at all? I'm not saying it would necessarily be better than the waveform for your needs, but it is similar but with slightly different buffer semantics. Would it be sensible to make similar changes to this?

Thanks,

- Andrew



Replies:
Re: double buffered waveformRecord Michael Davidsaver
References:
double buffered waveformRecord Michael Davidsaver
Re: double buffered waveformRecord Andrew Johnson
Re: double buffered waveformRecord Michael Davidsaver
Re: double buffered waveformRecord Andrew Johnson
Re: double buffered waveformRecord Ralph Lange
Re: double buffered waveformRecord Michael Davidsaver
Re: double buffered waveformRecord Michael Davidsaver

Navigate by Date:
Prev: Re: double buffered waveformRecord Michael Davidsaver
Next: Re: double buffered waveformRecord Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: double buffered waveformRecord Michael Davidsaver
Next: Re: double buffered waveformRecord Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  <20132014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·