Experimental Physics and
Industrial Control System

Michael Davidsaver <[email protected]> · Sun, 28 Oct 2018 20:24:07 -0700

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.

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.

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

My mistake was in not publishing record._options.atomic=True for Monitors.
This will be fixed the next time I work on QSRV.

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System