EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: Concerns about link-support-2 branch
From: "Johnson, Andrew N." <[email protected]>
To: Michael Davidsaver <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Tue, 7 Mar 2017 06:08:45 +0000
Hi Michael,

Please take another look, my changes have not modified the dbGetAlarm() or dbGetTimestamp() APIs at all, they still call straight through into the appropriate plset->getAlarm() and plset->getTimestamp() methods of the underlying link-type. Both the code samples you showed should still work without any changes.

The change I made in that commit was to the plset->getValue() method, which is called by the dbGetLink() API. Previously dbGetValue() would call recGblInheritSevr() itself after calling the plset->getValue() method as long as the return status wasn't an error; the only difference is that now the link type must make that call itself as part of the functionality of its getValue method. This does not change the functionality of the existing higher level API routines at all.

If you want to change the semantics of the API routines we can discuss any proposal you want to bring up, but the current link-support-2 branch changes don't currently make any that I know of.

- Andrew

-- 
Sent from my iPad

> On Mar 6, 2017, at 6:36 PM, Michael Davidsaver <[email protected]> wrote:
> 
>> On 01/13/2017 05:29 PM, Andrew Johnson wrote:
>> Hi Michael,
>> 
>> I looked through my commits to the link-suport-2 branch and the only
>> place I can see that might match your description from Tuesday appears
>> to be this one:
>> 
>> http://bazaar.launchpad.net/~epics-core/epics-base/link-support-2/revision/12781
>> 
>> which is one of only 2 commits where I made changes to the code inside
>> the dbCa.c implementation (as against just changing the function
>> pointers in the dbCa_lset structure, which happened more frequently).
>> 
>> This commit removed 2 arguments from the lset::getValue() routine:
> 
> This is the one.
> 
>>> === modified file 'src/ioc/db/dbLink.h'
>>> --- src/ioc/db/dbLink.h 2016-09-02 04:21:23 +0000
>>> +++ src/ioc/db/dbLink.h 2016-09-04 00:21:11 +0000
>>> @@ -52,7 +52,7 @@
>>> 
>>>     /* Get data */
>>>     long (*getValue)(struct link *plink, short dbrType, void *pbuffer,
>>> -            epicsEnum16 *pstat, epicsEnum16 *psevr, long *pnRequest);
>>> +            long *pnRequest);
>>>     long (*getControlLimits)(const struct link *plink, double *lo, double *hi);
>>>     long (*getGraphicLimits)(const struct link *plink, double *lo, double *hi);
>>>     long (*getAlarmLimits)(const struct link *plink, double *lolo, double *lo,
>> 
>> The pstat and psevr arguments were provided to allow the getValue()
>> routine to send alarm status & severity values from the target record to
>> the record owning the link when the appropriate link flags are set
>> (MS/MSS/MSI).
>> 
>> However all link types now have a pointer to their own record (it used
>> to be that only some link types had one), so a link support layer can
>> now set its owner's alarm status & severity directly using the
>> recGblInheritSevr() routine. Other changes in this commit implement that
>> for the CA and DB link types.
> 
> I wasn't thinking about this as a side-effect, though I guess it has been.
> 
> So with the proposed link support API, the atomicity I want would need
> to be achieved by implicit ordering of calls.  eg. calling dbGetValue()
> also latches time and alarm, which are returned by later dbGetAlarm()
> and dbGetTimestamp().
> 
> As an example of why I've wanted to get link severity explicitly.  An
> asub record which selects the first non-INVALID input.  This calls
> dbGetAlarm().
> 
> https://github.com/epicsdeb/mrfioc2/blob/6adeb3e87ef90aa06f8928ce2f341af03b00b8c3/evrApp/src/asub.c#L29
> 
> I also had some code which used links to populate a time based FIFO (eg.
> all samples in the past 60 min.) with statistics.  This required calling
> dbGetTimestamp() explicitly.  dbGetAlarm() as well to determine validity.
> 
> https://github.com/Sangil-Lee/Work/blob/03ce2bf4ac226b8ccc2498d45c5f671067357c8c/siteApps/srs725/nsls2App/src/timedbuffer.cpp
> 
> (this is an incomplete version which I must have sent to Sangil at some
> point.  It doesn't do anything except overflow the sample deque.  I'll
> see if I can dig up the working code.)
> 
> 
> I've also made use of TSEL to .TIME with CA_LINK a few times under the
> impression that value and time would always be consistent.  Apparently
> this is/has not been true.  I'd like to make it true!
> 
> 
> If the implicit order is undesirable, I suppose that want I'm after
> could also be accomplished by resurrecting the options interface w/
> dbGetLink() in a way that the link support can lock around all operations.
> 
> Not that I'm especially fond of the options API.
> 
> 
> 
>> In dbCa.c the commit does swap the order in which the pca->stat and
>> pca->sevr values are read to after the call to add_action(), but the
>> dbCaGetLink() routine is still holding the pca->lock at the time so the
>> dbCaTask can't modify the pca object yet. We could change that order
>> back again, but I don't see that it matters.
>> 
>> If I misunderstood and you were worried about some other change instead
>> please let me know which one.
>> 
>> - Andrew
> 


Replies:
Re: Concerns about link-support-2 branch Michael Davidsaver
References:
Concerns about link-support-2 branch Andrew Johnson
Re: Concerns about link-support-2 branch Michael Davidsaver

Navigate by Date:
Prev: Re: Concerns about link-support-2 branch Michael Davidsaver
Next: Re: Concerns about link-support-2 branch Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Concerns about link-support-2 branch Michael Davidsaver
Next: Re: Concerns about link-support-2 branch Michael Davidsaver
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  <20172018  2019  2020  2021  2022  2023  2024 
ANJ, 21 Dec 2017 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·