EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

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

Subject: Re: some field definitions
From: Tim Mooney <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: Core-Talk <[email protected]>, "Dalesio, Leo" <[email protected]>
Date: Mon, 27 Apr 2009 14:22:00 -0500
I think PUTF is essential for dbAccess. If you leave out the [] in the following, you get a record out of sync with the hardware it's driving, because a CA client
interfered with a database.

1) A CA put causes asynchronous record 'recA' to process [dbPutField sets recA.PUTF==1] 2) The first call to process returns, with recA.PACT==1, and the lockset unlocked 3) Somebody else processes record 'recB', which writes to recA.VAL via a PP link 4) The PP link succeeds in changing recA.VAL, but doesn't cause it to process,
because recA.PACT==1   [however, recA.PUTF==1, so recA.RPRO is set to 1]
5) recA completes processing started by the CA put

Now recA.VAL (written by the PP link) disagrees with the hardware it 's driving, and
this state persists until someone happens to process recA again.
[recA.RPRO causes recA to be scheduled for processing again]
[ recA.PUTF is cleared]

If we left out that "however, PUTF==1, so" then RPRO would be set because of
PACT==1 alone, and this would permit RPRO to cause an infinite loop of PP links.

Tim

Andrew Johnson wrote:
Hi Tim,

Thanks for thinking about this.

On Monday 27 April 2009 01:50:52 Tim Mooney wrote:
I think PUTF is for EPICS to keep track of whether a record was processed
by a CA client, or by a PP link.  EPICS uses this to decide whether break
a loop in a lockset (a PP link trying to process a record that's already
executing as the result of a PP link) or allow two independent actors to
process a record at overlapping times (accidental collision between a PP
link and a CA put).

The IOC can't distinguish between regular CA clients and CA links from itself or another IOC, and I don't see why it would want/need to do so. I *can* see it being useful for a record to be able to distinguish between processing caused by any kind of put and processing where no record field has been changed since last time -- if PUTF is false, it doesn't need to check if any of its configuration fields changed at all.

I don't think breaking loops can be the reason, since any loop you make with output links can also be made with input or forward links and PUTF is not examined at all in those cases. Loops are broken using the rule that PACT of a record containing DB links must be TRUE whenever another record is being processed through any of those links. This is enforced in dbScanLink() [which is called by dbPutLinkValue()] and in dbGetLinkValue(). This doesn't break a loop between two async records (which is where the RPRO field is needed), but that's a documented situation that we can't easily detect.

I'm not sure about your item 4, but I don't think a database link should ever result in PUTF being set. Also, I think
recGblFwdLink should clear PUTF always. If RPRO and PUTF are both set,
it means a record was processing because of a CA put, and a PP link tried
to process it, so the processing motivated by RPRO must be PP-link
processing.

The fact that we can't understand item 4 is why I think this is a historical artifact. With the change I proposed, PUTF tells the record whether any of its fields have been modified since it was last processed, which I maintain is useful information. Currently the *only* place we actually look at the value of PUTF is in dbPutLinkValue(), as described in my item 4.

Why would a record want or need to distinguish between being processed as the target of a DB vs a CA link or other CA client? Assuming that PUTF isn't required for reasons internal to dbAccess (which I think is the case), what would you *like* PUTF to mean? We could even make PUTF and/or RPRO into counters so you could tell how many fields were changed while your PACT field was marking you as busy (although we'd only reprocess it once).

- Andrew


Andrew Johnson wrote:
Hi Bob,

On Friday 24 April 2009 14:55:25 Bob Dalesio wrote:
Do you know what the PUTF record processed by dbPutfield, and RPRO
reprocess fields are used to accomplish?
I'm cross-posting this message to core-talk because while replying to
Bob's question I think I've found a couple of bugs associated with those
fields, and I'd like some more eyes on the issue.


I believe PUTF was provided as a way of telling a record that it's being
processed because someone changed one of its fields, so it can
distinguish between that and processing resulting from a forward link or
other scan mechanism.  I don't know of any record types that actually
look at PUTF, but there could be some.  However there are occasions where
PUTF lies, which makes it less useful (see below).

RPRO is needed to ensure that a pending asynchronous operation doesn't
cause the processing resulting from a put operation to be missed.  It is
less relevent to the record type, being mostly for internal use but is
related to the PUTF field.

Here's what I get from reading the source, which uses these two fields in
four places:

1. If something [usually CA but it could be a dbpf command] calls
dbPutField() to set a field which is marked as PP, the routine will try
to process the record immediately.  If PACT is true however it can't, so
it sets RPRO to request reprocessing later; if PACT is false it sets PUTF
and calls dbProcess() to do the actual processing.

2. Inside dbProcess(), if a record is found to be disabled because
DISA==DISV, both PUTF and RPRO are cleared immediately.

3. When a record finishes processing, usually the last thing its
process() routine does is to call recGblFwdLink().  This checks and
clears the RPRO field and if set it sticks this record on the scanOnce()
queue to be run again as soon as possible.  recGblFwdLink() always clears
PUTF.

4. In dbPutLinkValue() when a DB link from another record has the PP flag
set or points to the PROC field, if the destination record has its PUTF
field set it just sets RPRO.  If PUTF is not set, it calls dbScanLink()
to process the destination record.  This code really doesn't make any
sense to me.


I think there are two bugs in the above code, which make the PUTF field
less useful than it could/should be.

A) I suspect that in item 4 above, the dbPutLinkValue() code really
should be testing PACT not PUTF, and it should actually set PUTF before
the call to dbScanLink().  I have some vestigial memories that before
PACT was introduced the PUTF field was involved in asynchronous
processing, but I wasn't involved at the time so I may be confused about
that.

B) I also think that recGblFwdLink() should not clear PUTF if RPRO was
set, because the *next* time the record processes is the one that is due
to a call to dbPutField() or dbPutLink().  Instead it should be setting
PUTF if RPRO was set, and clearing it otherwise.


I propose to apply the attached change in src/db and would appreciate
comments from other core developers in case I've missed or misunderstood
something about how this is supposed to work.

Without this patch, PUTF is actually an almost useless field; the only
place where its value gets looked at is in the dbPutLinkValue() routine
as described above, unless there are some non-core record types that use
it.

- Andrew





--
Tim Mooney ([email protected]) (630)252-5417
Beamline Controls & Data Acquisition Group (www.aps.anl.gov/aod/bcda)
Advanced Photon Source, Argonne National Lab


References:
Re: some field definitions Andrew Johnson
Re: some field definitions Tim Mooney
Re: some field definitions Andrew Johnson

Navigate by Date:
Prev: Re: some field definitions Andrew Johnson
Next: Re: some field definitions Andrew Johnson
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: some field definitions Andrew Johnson
Next: Re: some field definitions Marty Kraimer
Index: 2002  2003  2004  2005  2006  2007  2008  <20092010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·