The ACI has support for retrieving values for single members of a struct
property in their primitive type, but not all members in their primitive
type. Only all members as a string representation of the entire property.
The string can then be manually parsed. One example of such usage is here:
https://gitlab.com/opencpi/opencpi/-/blob/develop/projects/assets/hdl/cards/fmcomms_2_3_rx.rcc/include/worker_prop_parsers_ad9361_config_proxy.h#L144

From your description it sounds like your property is volatile, for which
your concern of consecutive reads is valid. If the property is not volatile
or readable, then this concern would not entirely be valid, but would
certainly have other considerations.

---------- Forwarded message ---------
From: Brian Padalino bpadalino@gmail.com
Date: Fri, Apr 24, 2020 at 5:54 PM
Subject: [Discuss OpenCPI] Accessing Complex Properties (struct) of A Worker
To: discuss@lists.opencpi.org

I have an application where multiple items need to be read out at the same
time for a single property.  They are intimately related to each other.  So
I have a structure property with multiple members.  I have a readsync setup
so that I can set all the members at once based on some internal states.
But it's very important that they all be updated at the same time.
Multiple reads are not useful.

I saw section 7.1.7.1 of the Application Development guide:

https://opencpi.github.io/OpenCPI_Application_Development.pdf

But it's unclear how to get all the values of the struct out at once.  Is
this possible?  Am I just reading that document incorrectly?

Thanks,
Brian

I'll put forth a more restricted answer.  The ACI can read volatile
property values of all types, whole and in part.
In all cases you can get the value returned as a formatted string
according to the documented textual format.
When the values being read (whole or part) are scalars or
arrays/sequences of scalars, they can also be read directly as binary
values.

These restrictions come down to the fact that OpenCPI does not perform
data type code generation for the ACI.

One idea that has been floated is to use Google's flatbuffers for this
purpose.

On Sat, Apr 25, 2020 at 8:13 AM James Kulp <jek@parera.com
mailto:jek@parera.com> wrote:

 I'll put forth a more restricted answer.  The ACI can read volatile
 property values of all types, whole and in part.
 In all cases you can get the value returned as a formatted string
 according to the documented textual format.
 When the values being read (whole or part) are scalars or
 arrays/sequences of scalars, they can also be read directly as binary
 values.

 These restrictions come down to the fact that OpenCPI does not
 perform
 data type code generation for the ACI.

Sure - that's very understandable.

 One idea that has been floated is to use Google's flatbuffers for
 this
 purpose.

I won't comment on the binary reading part, but I would definitely
recommend changing the string data exchange format to be JSON instead
of what you have.  There is a great JSON library for C++11 which makes
super easy to use objects and is MIT licensed:

https://github.com/nlohmann/json

Now, for something back on topic.  I had setup the readsync
functionality, but forgot to set it to volatile. When I did this, the
read() method was called for syncing, but the data was never updated. 
Is this expected behavior? I would think that readsync would imply
volatile.  Are there cases where readsync would be set, but volatile
shouldn't be assumed?

Lastly, there's a lot of XML happening for all these different
devices, workers, platforms, etc.  Is there a comprehensive XML schema
that can be referenced for each of the XML data types?

Thanks,
Brian

Now, for something back on topic.  I had setup the readsync functionality,
but forgot to set it to volatile.  When I did this, the read() method was
called for syncing, but the data was never updated.  Is this expected
behavior?  I would think that readsync would imply volatile.  Are there
cases where readsync would be set, but volatile shouldn't be assumed?

It is expected since you never said the value would change.

Having a readsync imply volatile is sensible, but a bit magical.

It would also eliminate the functionality of a readsync on non-volatile
values (i.e. tell me when it is accessed even if I won't change it after
start).
I.e. it would make the two issues tied together rather than independent of
each other.

Lastly, there's a lot of XML happening for all these different devices,
workers, platforms, etc.  Is there a comprehensive XML schema that can be
referenced for each of the XML data types?

Since we use a very compact runtime parser for XML, it was not ever
attractive to have that parser be schema-driven, since that would bloat it,
by 2 orders of magnitude last time we checked.

Even if there was a schema, it is far from sufficient for knowing whether
XML is correct, so there is always more validation that must be coded
separate from the schema.

And schema-based parsers cannot provide semantic errors.

That being said there are three pretty clear deficiencies in this area:

1. Some people want it to all be yaml, and some want it all to be json :-)

2. There is no simple standalone validation tool in OpenCPI - you have to
   "build" and get errors.

3. The syntax-level (schema-level) error reporting is not great.

Thanks,
Brian