Experimental Physics and
Industrial Control System

Timo Korhonen <[email protected]> · Mon, 29 Oct 2018 12:05:06 +0000

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".

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

>
>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.

Best regards,

Timo

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System