Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Mon, 29 Oct 2018 07:07:48 -0700

On 10/29/18 5:05 AM, Timo Korhonen wrote:
> Hi Michael,
> 
> Thank you for the clarification.
> 
> 
> On 29/10/18 04:24, "Michael Davidsaver" <[email protected]> wrote:
> 
>> On 10/26/18 3:45 AM, Timo Korhonen wrote:
>>> Hi,
>>>
>>> I guess this is addressed to Michael but maybe this is a question worth
>>> asking in the group:
>>>
>>> I am wondering about the difference in group PV atomicity. I tried to
>>> follow the circle.db example.
>>> It seems to work as I expected. However, when I use pvget:
>>>
>>> $ pvget circle
>>>
>>> circle
>>>
>>> epics:nt/NTTable:1.0
>>>
>>>     structure record
>>>
>>>         structure _options
>>>
>>>             uint queueSize 0
>>>
>>>             boolean atomic true
>>
>> Ah, so someone has noticed.  My idea here was to provide a means for
>> a user to ascertain what the effect of pvRequest options are.  And also
>> which options are actually valid.
> 
> I actually want to use this, so I also want to understand what is going on
> ;-)
> 
>>
>> However, as you've found, I didn't complete this.  I actually didn't
>> notice this until sometime after I last worked on QSRV.
>>
>> ...
>>> The attribute "atomic" is true, as I expected (set it using info tags).
>>> But with monitoring, I get:
>>
>> ...
>>> for the same group pv.
>>> Trying to dig into the code (I have not been able to go deep), I see
>>> references to "pgatomic" and "monatomic".
>>> This suggests to me that there is a difference in  how monotonicity is
>>> set/handled with monitors. Is this true? How can one make groups be
>>> handled atomically?
>>> Or is this just my over-interpretation?
>>> I tried to figure this out from the documentation but I could not.
>>
>> The confusion is that 'atomic' for a Get (and more importantly a Put)
>> can be controlled via a pvRequest option.  The default is what was
>> given via "+atomic:" in the info() group configuration.
> 
> Aha, good to know.
>>
>> However, it is not presently possible to override this for a monitor.
>> There is no fundamental reason, just a question of my not having done
>> so.  Thus group monitors are always "atomic".

oops.  On re-reading, this is not correct.  What I should have said is that
it is not possible to override the "atomic" setting in a pvRequest.
The info() tag configuration is always used.  This may be 'false'.

> Is there a downside, or a reason for the group monitor, or get, not being
> atomic?
> Some kind of performance penalty maybe?

A non-atomic group monitor could be used as something like an aggregation
of individual subscriptions as a convenience.  I don't have a use case in
mind.  The option is there because the code path is there anyway to handle
DBE_PROPERTY.

>>
>> My mistake was in not publishing record._options.atomic=True for Monitors.
>> This will be fixed the next time I work on QSRV.
> 
> OK, this is good to know, no problem.
> 
>>
>>
>> I say "atomic" because this is more like a triggered Get as it
>> (necessarily)
>> bypasses the dbEvent queue in much the same way that with array fields
>> (as in waveformRecord.VAL).
>>
>> Making use of the dbEvent queue in this situation would require
>> introducing some
>> notion of ordering between related subscriptions, and maybe also to tie
>> in with
>> processing/locking to determine when a group update has "finished".
> 
> I have to let this sink in for a while before I can picture how this works
> under the hood.

The central part is

https://github.com/epics-base/pva2pva/blob/95b23fc6bc5407cea76c42fd9db43850ee5db751/pdbApp/pdbgroup.cpp#L46-L62

Note where the 'pfl' argument is used, and where it isn't.

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System