EPICS Home

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: Michael Davidsaver <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Mon, 6 Mar 2017 19:36:02 -0500
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
Re: Concerns about link-support-2 branch Johnson, Andrew N.
References:
Concerns about link-support-2 branch Andrew Johnson

Navigate by Date:
Prev: RE: const-constraints on struct rset method arguments Ron Sluiter
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: Concerns about link-support-2 branch Andrew Johnson
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