Re: DBE_PROPERTY events

["Johnson, Andrew N. via Core-talk" <core-talk at aps.anl.gov>]

On 8/29/24, 10:11 AM, Michael Davidsaver via Core Talk wrote:

 

On 8/29/24 06:20, Zimoch Dirk via Core-talk wrote:
> Checking the EPICS base code, I found thus in dbPut():
>      /* If this field is a property (metadata) field,
>       * then post a property change event (even if the field
>       * didn't change).
>       */
>      if (precord->mlis.count && pfldDes->prop)
>          db_post_events(precord, NULL, DBE_PROPERTY);
>
> So this behavior is on purpose, but I wonder why.

This was an explicitly made technical shortcut to get this feature in.

dbCore has no mechanism for previous value tracking, with this instead being left
to individual record support to handle.  Doing otherwise would seem to require
keeping a uniform previous value for every field, or eg. somehow encoding an
association between value and previous value into the DBD.

The above code is inside the dbPut() routine that modifies the field being referred to, so earlier on it does have access to the old field value before the write happens, and to the new value after the write. Property fields (i.e. fields that have pfldDes->prop set to indicate they hold metadata) are all simple and can’t be arrays or double-buffered, so it might not be too hard to copy the old value before writing to it, then compare the new value afterwards to determine whether to post this change. The code that stores the old value and later compares it should only do those things for property fields when someone is monitoring this record (the condition in the if above), which should be a small overhead.

Thus I could see this as being possible, my analysis agrees with Dirk’s. I don’t have an objection to doing that as long as the measured performance isn’t significantly different.

- Andrew

-- 

Complexity comes for free, Simplicity you have to work for.