ISO C++ DDS PSM

Angelo Corsaro, Ph.D.Chief Technology Officer

OMG DDS SIG [email protected]

Delivering Performance, Openness, and Freedom

OpenSplice DDS

ISO C++ DDS PSM

mailto:[email protected]


D e l i v e r i n g P e r f o r m a n c e , O p e n n e s s , a n d F r e e d o m

OpenSplice DDS

Rationale

© 2010, PrismTech. All Rights Reserved

ISO C++ PSM Motivations

The “Native C++ Language DDS PSM” (CxxDDS) was motivated by the following reasons:

‣Provide better integration with the C++ programming language

‣Provide a simpler and safer API to facilitate adoption within and beyond current user domains

‣Ensure 100% source-code portability across DDS implementations


Integration with C++

The current IDL-derived PSM suffers the following shortcomings:

‣Limited integration of IDL-derived types with the C++ language‣e.g. char* vs. std::string, Sequence vs. std::vector, etc.

‣Limited use of features and idioms universally supported by C++ compilers and widely used by C++ programmers‣e.g. template and template-meta-programming, iterators, etc.


API Complexity

‣The current API suffers from accidental complexity mostly induced by the limited expressiveness of IDL and the dated IDL2C++ mapping


Portability

‣The current IDL-derived API leaves some types defined as native, thus allowing different vendors to use different representations‣e.g. the type of the domainid‣The current IDL-derived API does not specifies the DDS interfaces

as local, yet semantically those are local. This has also been source of portability issues


OpenSplice DDS

Submission OverviewFoundations


CxxDDS API Organization

‣Different packages are introduced to limit the dependencies and group together relevant classes

‣ The submission separates clearly those files features that are specific to publication and subscription so that application can include only the minimal set of files

‣ The API is parametrized w.r.t. a DELEGATE layer


Delegation Layer‣ The delegation layer, is provided by vendors and used to instantiate the CxxDDS API

into a concrete API

‣ This standard provide a reference implementation that shows how that can be done.

‣ Under any circumstances, compliant implementation shall not change the CxxDDS API, as detailed in Section 8, vendor-specific extensions shall be added only via DELEGATEs.

‣ The CxxDDS API provides a standard way of accessing vendor specific extensions

‣ Finally, although the specification allows for vendor-specific extensibility, it should be clear that this specification does not encourage nor recommend their use

Using vendor specific extensions will make application non-source-code-portable to other CxxDDS compliant implementations and might also adversely impact on-the-wire interoperability.


Object Model

The Native C++ Language DDS PSM (CxxDDS) is based on an object model structured in two different kinds of object types: reference-types and value-types


Reference Types

‣ Reference-types have a shallow (polymorphic) assignment operator that simply changes the value of the reference

‣ Reference-types are safe. Under no circumstances a reference can point to an invalid object.

‣Memory for reference-types is automatically managed by the runtime.

Impl.

Ref

Ref

Ref

CxxDDS Delegate (provided by a specific vendor implementation)


Reference Types (cont.)

‣ The semantics for Reference types is defined by the CxxDDS class dds::core::Reference.

‣ The specification mandates the semantics implied by the Reference class, yet the implementation provided as part of this standard is provided to show one possible way of implementing this semantics

namespace dds { namespace core { template <typename DELEGATE> class Reference;}}


Reference Types


WeakReferences

‣ The CxxDDS also provides safe Weak References implemented by the class dds::core::WeakReference

‣Weak References can be constructed only from strong references

‣Weak References do not expose other method other than checking wether the reference is valid and getting a strong-reference

namespace dds { namespace core {template <typename class R <typename D>> class WeakReference;}}


Value Types

‣ All objects that have a value-type have a deep-copy assignment semantics.

‣ It should also be pointed out that value-types are not “pure-value-types” in the sense that they are immutable (as in functional programming languages).

‣ The CxxPSM makes value-types mutable to limit the number of copies as well limit the time-overhead necessary to change a value-type (note that for immutable value-types the only form of change is to create a new value-type).

‣ Value-types always inherit from the CxxPSM dds::core::Value

The CxxDDS models all DDS entities as reference-types while QoS and Topic samples are all modeled as value-types.


API Extensibility

‣ The CxxPSM allows for QoS to be extended, either by new version of the standard or by vendor specific extension without any impact on the public API.

‣ The CxxPSM provides this level of extensibility while also enjoying a very compact representation of a QoS which leverages the combination of a DELEGEATE QoS implementation along with template getter and setters.


QoS as an Example of Extensibilitynamespace dds { namespace core { template <DELEGATE>class Value;template <typename DELEGATE> class EntityQoS : public Value<DELEGATE> { public: DDS_VALUE_TYPE(EntityQoS,DELEGATE)public: template <typename... ARGS> EntityQoS(ARGS... args) : impl_(args...) { }

template <typename POLICY> void set_policy(const POLICY& qos) { impl_.set_policy(qos); } template <typename POLICY> QOS get_policy() const { return impl_.get_policy<POLICY>(); }}; } } /* namespace dds / namespace core */

Although the CxxPSM specifies the EntityQoS by leveraging variadic C++ templates for providing a constructor taking an arbitrary number or arguments, some implementation might have to leverage other techniques for emulating variadic templates on non-supported compilers. The standard technique for doing this is to define several template constructors accepting an increasing number of arguments.


Primitive Types Mapping

‣ The CxxDDS API provides its own interoperable definition of DDS primitive types and represents them in terms of standard (and portable) C/C++ types.


Sequence Mapping

‣Bounded and Unbounded IDL Sequences for a type T map to std::vector<T>


Parameters Passing

Constant-size Primitive types

‣ in T => T

‣ out T => T&

‣ inout T => T&

Variable-size Primitive types (e.g string, wsting)

‣ in T => const T&

‣ out T => T&

‣ inout T => T&


Parameters Passing

Value Types


‣ out T => T&

‣ inout T => T&

Reference Types


‣ out T => T&

‣ inout T => T&


Return Parameters

Attribute Accessors for fixed-size primitive types

‣ T => T

Attribute Accessors for any other type

‣ T => const T&

Non-attribute return-values

‣ T => T


OpenSplice DDS

Submission OverviewAPI Overview


DDS Entities


Entity QoS

‣ To improve the level of compile time error detection, the current submission separates the initialization of entity QoS policy from the update of some of its policies.

template <typename DELEGATE> class Publisher : public dds::core::Entity<DELEGATE> { public: // -- QoS related methods -- template <typename POLICY> void set_policy(const POLICY& p) { impl_->set_policy(p); } template <typename POLICY> const POLICY& get_policy() const { return impl_->get_policy(); } dds::PublisherQos get_qos() const { return impl_->get_qos(); } // -- Other Publisher Methods not shown // for space constraints };


QoS Extensibility

‣The current submission provides two ways of providing vendor specific QoS

XYZVendorTopicQoS vtqos = { /* values */ }; dds::Topic<MyType> topic("MyTopic", vtqos);

Vendor-specific DDS Entity QoS (topic in this case)

dds::Topic<MyType> topic("MyTopic"); XYZVendorPolicy policy = { /* values */ }; topic.set_policy(policy);

Vendor-specific QoS Policy (topic in this case)


Reading/Taking Data

The new API simplify and extends the ways in which data can be read/taken by providing:

‣ std::vector based reads/takes

‣The std::vector API allows for zero copy optimization

‣ Iterators based read/take supporting both:

‣Forward Iterators

‣Back Inserting Iterators


std::vector-based read/take /** * Reads all new samples from any view state and alive instances. If the provided containers have * zero-size than the middleware will loan memory to the application to support zero-copy reads. * The memory will be returned to the middleware when the container is destroyed or by explicitly * invoking the <code>return_loan</code> method on the data reader. */ void read(std::vector<T>& samples, dds::SampleInfoSeq& infos); /** * Reads at most <code>max_samples</code> samples that have not been read yet from all views * and alive instances. */ void read(std::vector<T>& samples, uint32_t max_samples); /** * Most generic <code>read</code> exposing all the knobs provided by * the OMG DDS API. */ void read(std::vector<T>& samples, dds::SampleInfoSeq& infos, uint32_t max_samples, dds::SampleStateMask samples_state, dds::ViewStateMask views_state, dds::InstanceStateMask instances_state);


std::vector-based take /** * Reads all new samples from any view state and alive instances. If the provided containers have * zero-size than the middleware will loan memory to the application to support zero-copy reads. * The memory will be returned to the middleware when the container is destroyed or by explicitly * invoking the <code>return_loan</code> method on the data reader. */ void take(std::vector<T>& samples, dds::SampleInfoSeq& infos); /** * Reads at most <code>max_samples</code> samples that have not been read yet from all views * and alive instances. */ void take(std::vector<T>& samples, uint32_t max_samples); /** * Most generic <code>read</code> exposing all the knobs provided by * the OMG DDS API. */ void take(std::vector<T>& samples, dds::SampleInfoSeq& infos, uint32_t max_samples, dds::SampleStateMask samples_state, dds::ViewStateMask views_state, dds::InstanceStateMask instances_state);


FWD-Iterator-based read /** * Reads new samples from any view state and alive instances. */ template <typename SamplesFWIterator, typename InfoFWIterator> void read(SamplesIterator sfit, InfoIterator ifit, uint32_t max_samples); /** * Reads at most <code>max_samples</code> samples that have not been read yet from all vies and * alive instances. */ template <typename SamplesFWIterator> void read(SamplesFWIterator samples, uint32_t max_samples); /** * Most generic <code>read</code> exposing all the knobs provided by * the OMG DDS API. */ template <typename SamplesFWIterator, typename InfoFWIterator> void read(SamplesFWIterator sfit, InfoFWIterator ifit, uint32_t max_samples, dds::SampleStateMask samples_state, dds::ViewStateMask views_state, dds::InstanceStateMask instances_state);


FWD-Iterator-based take /** * Reads new samples from any view state and alive instances. */ template <typename SamplesFWIterator, typename InfoFWIterator> void take(SamplesIterator sfit, InfoIterator ifit, uint32_t max_samples); /** * Reads at most <code>max_samples</code> samples that have not been read yet from all vies and * alive instances. */ template <typename SamplesFWIterator> void take(SamplesFWIterator samples, uint32_t max_samples); /** * Most generic <code>read</code> exposing all the knobs provided by * the OMG DDS API. */ template <typename SamplesFWIterator, typename InfoFWIterator> void take(SamplesFWIterator sfit, InfoFWIterator ifit, uint32_t max_samples, dds::SampleStateMask samples_state, dds::ViewStateMask views_state, dds::InstanceStateMask instances_state);


BI-Iterator-based read /** * Reads all new samples from any view state and alive instances. */ template <typename SamplesBIIterator, typename InfoBIIterator> void read(SamplesIterator sbit, InfoIterator ibit); /** * Most generic <code>take</code> exposing all the knobs provided by * the OMG DDS API. */ template <typename SamplesBIIterator, typename InfoBIIterator> void read(SamplesBIIterator ifit, InfoBIIterator ifit, dds::SampleStateMask samples_state, dds::ViewStateMask views_state, dds::InstanceStateMask instances_state);


BI-Iterator-based take /** * Reads all new samples from any view state and alive instances. */ template <typename SamplesBIIterator, typename InfoBIIterator> void take(SamplesIterator sbit, InfoIterator ibit); /** * Most generic <code>take</code> exposing all the knobs provided by * the OMG DDS API. */ template <typename SamplesBIIterator, typename InfoBIIterator> void take(SamplesBIIterator ifit, InfoBIIterator ifit, dds::SampleStateMask samples_state, dds::ViewStateMask views_state, dds::InstanceStateMask instances_state);


Conditions


Creating a Condition (ex.)

/** * Creates an <code>ActiveReadCondition</code> that waits for new samples to * be arriving in order to notify. */ template <typename F> ::dds::Condition create_readcondition(const F& f);


OpenSplice DDS

Submission OverviewWriting an application


IDL as Usual

enum TemperatureScale {! CELSIUS,! KELVIN,! FAHRENHEIT};!struct TempSensorType {! short id;! float temp;! float hum; TemperatureScale scale;

};#pragma keylist TempSensor id


Writer: As simple as it gets

/********************************************************** * DataWriter **********************************************************/dds::Topic<TempSensorType> tsTopic("TempSensorTopic");// Create a Publisher connected to the proper partition// Create a DataWriterdds::DataWriter<TempSensorType> dw(tsTopic);

TempSensorType ts = {1, 26.0F, 70.0F, CELSIUS};// Write Datadw.write(ts);


Customizing the Writer QoS

/********************************************************** * DataWriter **********************************************************/dds::DomainParticipant dp(did);dds::Publisher pub(dp, pqos);dds::Topic<TempSensorType> tsTopic("TempSensorTopic");// Create a Publisher connected to the proper partition// Create a DataWriterdds::DataWriter<TempSensorType> dw(tsTopic, pub, dwqos);

TempSensorType ts = {1, 26.0F, 70.0F, CELSIUS};// Write Datadw.write(ts);


Data Reader/********************************************************** * DataReader **********************************************************/dds::Topic<TempSensorType> tsTopic("TempSensorTopic");// Create a DataReaderdds::DataReader<TempSensorType> dr(tsTopic);

// If no initial size is provided than the read will read// all available samplesstd::vector<TempSensorType> data;SampleInfoSeq info; // This is a std::vector too!

while (true) { dr.read(data, info); for (int i = 0; i < data.length(); ++i) std::cout << data[i] << std::endl; sleep(1);


Data Reader (with FW Iterators)/********************************************************** * DataReader **********************************************************/

dds::Topic<TempSensorType> tsTopic("TempSensorTopic");// Create a DataReaderdds::DataReader<TempSensorType> dr(tsTopic);

std::vector<TempSensorType> data(length);SampleInfoSeq info(length); // This is a std::vector too!

while (true) { dr.read(data.begin(), info.begin(), length); for (int i = 0; i < data.length(); ++i) std::cout << data[i] << std::endl; sleep(1);}


Data Reader (with BI Iterators)/********************************************************** * DataReader **********************************************************/

dds::Topic<TempSensorType> tsTopic("TempSensorTopic");// Create a DataReaderdds::DataReader<TempSensorType> dr(tsTopic);

std::vector<TempSensorType> data;SampleInfoSeq info; // This is a std::vector too!std::back_insert_iterator<std::vector<TempSensorType>> bid(data);std::back_insert_iterator<SampleInfoSeq> bii(info);while (true) { dr.read(bid, bii); for (int i = 0; i < data.length(); ++i) std::cout << data[i] << std::endl; sleep(1);


OpenSplice DDS

Interoperability with IDL2C++ API and CORBA


C++2IDL and CORBA Interop

‣ The new mapping defines implicit conversion methods to create the equivalent C++2IDL type when needed

‣ This allows to pass a new DDS Type to a CORBA call by leveraging automatically generated conversions

‣ Conversion can be enabled/disabled via IDL compilers flags


OpenSplice DDS

Résumé & Next Steps


Résumé

‣ The CxxDDS addresses the goals of the RFP by providing a simpler, safer and well integrated C++ API for DDS

‣ The current submission addresses extensibility and portability

‣ Efficiency and determinism is not impacted by the higher level of abstraction


Next Steps

‣ Vote a finalized version of this submission on June Meeting

Online Resources

http://www.opensplice.com/

emailto:[email protected]

http://www.youtube.com/OpenSpliceTube http://opensplice.blogspot.com

http://bit.ly/1Sreg


http://www.slideshare.net/angelo.corsaro

http://twitter.com/acorsaro/

http://www.prismtech.com/opensplice-dds








http://bit.ly/1Sreg

http://bit.ly/1Sreg






Thank You...

Date post:	06-Jul-2015
Category:	Technology
Upload:	angelo-corsaro
View:	2,064 times
Download:	0 times