Hi Michael,
Assuming the process_record_li() routine is for triggering record
processing after some I/O has been received, why is it unconditionally
setting pli->pact? This looks to me like a cross between an asynchronous
I/O completion routine (i.e. part of an asynchronous read_longin()
device support method) and something for triggering record processing.
It isn't thread-safe; it accesses two pli fields in the second if()
condition without holding the record's scan-lock, which has been illegal
in all Base versions for quite a long time. Is there an associated
longin device support that goes along with this?
Is the I/O operation the only thing that causes this record to process?
The fact that you're getting SCAN/INVALID alarms suggests that something
else is going on as well, but I can't tell what from just the code you
showed us.
This might have worked in 3.14.12, but since it isn't following the
rules so there is no guarantee what it will do in other versions.
Sorry to be so blunt,
- Andrew
On 09/27/2017 03:30 PM, Dunning, Michael wrote:
> After upgrading to Base 3.15.5, we are seeing what looks like
> double-processing of a certain custom record type. It is from our
> device support for Bira Ethernet Power Supply Controllers. The problem
> is with this record:
>
> record(longin, "ESB:BEND:2110:GainADCRaw")
> {
> field(DESC, "ADC Gain Raw Data")
> field(ASG, "Internal")
> field(DTYP, "EtherPSC")
> field(INP, "#L0 N0 P0 S50 @172.27.248.43")
> field(FLNK, "ESB:BEND:2110:GainADC.PROC")
> }
>
>
>
> When the IOC boots, the record has STAT: SCAN and SEVR: INVALID. If
> we camonitor this record, it seems to be processed twice:
>
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:15.648796 529
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:15.648796 529 SCAN INVALID
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:16.549097 534
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:16.549097 534 SCAN INVALID
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:17.449359 543
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:17.449359 543 SCAN INVALID
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:18.349763 549
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:18.349763 549 SCAN INVALID
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:19.250071 551
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:19.250071 551 SCAN INVALID
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:20.150256 549
> ESB:BEND:2110:GainADCRaw 2017-09-10 20:12:20.150256 549 SCAN INVALID
>
>
>
> The double-processing explains the SCAN and INVALID states.
>
> Here is the record processing routine from device support:
>
> static void process_record_li( ETHERPSCNODE *node, int signal, long i )
> {
> PSCRECORD *PSCRecord;
> struct longinRecord *pli;
> struct rset *prset;
>
> PSCRecord = &node->record[signal];
> if ( ! (pli = (struct longinRecord*) PSCRecord->precord) ) return;
>
> if ( pli->val != i || pli->udf || PSCRecord->nsta )
> {
> PSCRecord->nsta = NO_ALARM;
> PSCRecord->val.li = i;
> prset = (struct rset *) pli->rset;
>
> dbScanLock( (struct dbCommon*) pli );
> pli->pact = TRUE;
> (*prset->process)( pli );
> dbScanUnlock( (struct dbCommon*) pli );
> }
> }
>
>
>
> I confirmed that this problem doesn't occur with Base 3.14.12.4. Does
> anyone have any idea why this record would be processed twice with
> Base-3.15?
>
>
>
>
>
> Michael Dunning
> SLAC National Accelerator Laboratory
> 2575 Sand Hill Road
> Menlo Park, CA 94025
> (650) 926-5200
>
--
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon
- Replies:
- Re: Record processing twice after upgrading to Base 3.15.5 Dunning, Michael
- References:
- Record processing twice after upgrading to Base 3.15.5 Dunning, Michael
- Navigate by Date:
- Prev:
Record processing twice after upgrading to Base 3.15.5 Dunning, Michael
- Next:
Re: registerRecordDeviceDriver.pl takes a long time to finish Luca Cavalli
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Record processing twice after upgrading to Base 3.15.5 Dunning, Michael
- Next:
Re: Record processing twice after upgrading to Base 3.15.5 Dunning, Michael
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
<2017>
2018
2019
2020
2021
2022
2023
2024
|