C++ PSM for DDS: Revised Submission


Published on

Presentation from September, 2010 about the RTI proposal to improve the C++ API for the OMG's Data Distribution Service specification (DDS). See also http://code.google.com/p/dds-psm-cxx/.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • C++ is hard: there are many ways to do any given thing, and many pitfalls along the way. We’ll get there.
  • Just 1 header to include. It’s the same for all implementations.
    Namespaces aligned with packages in Java PSM proposal: easier training across languages.
    Start creating entities.
    Names and API patterns parallel to other PSMs for cross training.
    Smart pointers provide safety.
    Create topic.
    Type registration is automatic.
    Template parameter provides static type safety through reader/writer creation (…and enables automatic type registration).
    Create publisher. Overloads make passing QoS, listener, listener mask optional.
    Create writer. Templates remove the need for a cast or a generated writer type name.
    Write data. Instance handle, time stamp are optional parameters.
    Closing the participant automatically closes all of the contained entities. “Close” instead of “delete” avoids keyword collision, parallels Java PSM proposal, JMS, popular stream APIs.
  • Participant, topic, subscriber, reader created much like we saw before.
    WaitSet created with a factory method to maintain consistency with other reference types. Condition attached as in other PSMs.
    Loaned data and metadata are encapsulated in “LoanedSamples” class. Semantics explicit in name. Loan returned using canonical RAII pattern.
    Examine samples using canonical STL-style iterator pattern.
    Dereference iterator to get sample. Data and metadata are encapsulated as in Java PSM proposal.
    Want a copy instead of a loan? One method call; PSM itself doesn’t need to do anything. Cuts size/complexity of reader API in half.
  • C++ PSM for DDS: Revised Submission

    1. 1. The Real-Time Middleware Experts C++ PSM for DDS: Revised Submission September 2010 Rick Warren, Principal Engineer rick.warren@rti.com
    2. 2. Agenda  Specification Overview – Submitters fully engaged with strong working relationship— yes, really – We’re almost done—yes, really  Significant features of the specification – Writing data – Reading data – Resource management: contract and API idioms  TODO for the final submission – Add DDS-XTypes APIs – Resolve final differences between RTI and PrismTech proposals Copyright © 2010 RTI - All rights Reserved 2
    3. 3. This is the dark before the dawn  From the outside, you see: – Previously: joint submissions. Now: separate submissions. – Another round to go before the specification is complete  From the inside, we see: – Greatly increased engagement and activity from ourselves and our partner – Significant gains in completeness, consistency, and maturity since the last submission – Resolution of significant differences between the visions of the submitters Copyright © 2010 RTI - All rights Reserved 3
    4. 4. Goals  Improve user experience – Standard containers, e.g. std::string, std::vector – Modern, consistent, rigorous error handling: exceptions – Scalable learning curve: learning the next thing shouldn’t force you to relearn everything you’ve done so far  Improve portability – Standard headers, obtained directly from OMG – “Porting” is just a recompilation  Improve safety – Templates for type safety – Smart pointers for referential integrity Copyright © 2010 RTI - All rights Reserved 4
    5. 5. Where we are now  Specification changes since Minneapolis: – Complete DCPS proposal • + methods to set QoS based on profiles, à la DDS for LwCCM – Buildable example code – Consistent resource management contract – Consistent error management – Significant alignment with Java PSM proposal  Differences between RTI and PrismTech proposals: – Creation pattern for reference types – Aspects of QoS modification, incl. use of operator overloads – Memory management of listeners – Write/read/take overloads – Assorted minor details  Following reflects the RTI proposal Copyright © 2010 RTI - All rights Reserved 5
    6. 6. Example: Writing Data #include <omg/dds.hpp> using dds::domain::…; using dds::topic::…; using dds::pub::…; DomainParticipant dp = TheParticipantFactory().create_participant(); Topic<RadarTrack> tp = dp.create_topic<RadarTrack>("Radar Tracks"); Publisher pub = dp.create_publisher(); DataWriter<RadarTrack> dw = pub.create_datawriter(tp); RadarTrack sample; …; dw.write(sample); dp.close(); Copyright © 2010 RTI - All rights Reserved 6
    7. 7. Example: Reading Data DomainParticipant dp = …; Topic<RadarTrack> tp = …; Subscriber sub = dp.create_subscriber(); DataReader<RadarTrack> dr = sub.create_datareader(tp); WaitSet ws = WaitSet::create(); ws.attach_condition(dr.create_readcondition()); while (true) { ws.wait(); LoanedSamples<RadarTrack> dt = dr.take(); for (LoanedSamples<RadarTrack>::Iterator it = dt.begin(); it != dt.end(); ++it) { const Sample<RadarTrack>& sample = *it; if (sample.is_valid_data()) { const RadarTrack& data = sample.data(); // … } } vector<Sample<RadarTrack>> my_copy(dt.begin(), dt.end()); } // loan returned automatically using RAII pattern Copyright © 2010 RTI - All rights Reserved 7
    8. 8. Resource Management  Principles – Safety: Never access uninitialized, freed, or undefined state – Determinism: Applications have control over when local and remote resources are allocated and released – Expressiveness: Maintain capabilities from PIM  Expression of principles differ for different kinds of types – Reference types: Strong concept of identity, based on reference • Entities • Wait sets and conditions – Value types: Weak concept of identity, based on state • Entity QoS and QoS policies • Status • Time and duration Copyright © 2010 RTI - All rights Reserved 8
    9. 9. Resource Management: Reference Type Usage  Access is through smart pointers, allocated by factory methods. These: – Provide null initialization – Throw exception on access to “closed” object – May automatically manage resources (more later…)  Examples: – Null pointer: • Publisher pub; • if (pub == dds::core::null) { … } – Initialization: • pub = dp.create_publisher(); – Copying reference: • Publisher pub2 = pub1; —or— Publisher pub2(pub1); // 2 references to same object – Casting: • Publisher pub = dynamic_ref_cast<Publisher, Entity>(my_entity); —or— • Publisher pub2(my_entity); Copyright © 2010 RTI - All rights Reserved 9
    10. 10. Resource Management: Reference Type Mgmt  Reference types have close() method – Disposes object and its contained objects – Recommendation: use it  Service may automatically close objects no longer in use – “May” gives vendors flexibility to balance determinism, convenience for their users – Similar to resource management practice in JMS – Common-sense rules: • If I keep a reference to it, I intend to call it: still in use • If I set a listener, I want it to call me: still in use • If I call retain(): still in use  Summary: – Deterministic way to halt communication, reclaim resources – Deterministic way to continue communication, maintain resources – Flexibility for vendors to adapt, community to learn Copyright © 2010 RTI - All rights Reserved 10
    11. 11. Resource Management: Value Type Usage  Access is by value, allocated on the stack – Deeply allocated by constructor – Disposed by destructor  Examples: – Initialization: • Default value: Duration d; • Custom value: Duration d(sec, nanosec); – Copying value: 1. Duration d2 = d1; —or— Duration d2(d1); 2. assert(d2 == d1); // overloaded assignment, comparison ops 3. d2.sec() = 5; 4. assert(d2 != d1); // independent state Copyright © 2010 RTI - All rights Reserved 11
    12. 12. Resource Management: Value Type: QoS  Entity QoS must be constructed by copying – Correct PublisherQos q = dp.get_default_publisher_qos(); – Incorrect: PublisherQos q; // won't compile  QoS modification idiom: 1. Start with current or default values 2. Modify them as desired 3. Set the new values back  Prevent accidental QoS clobbering or ignoring Copyright © 2010 RTI - All rights Reserved 12
    13. 13. Resource Management: Value Type: QoS // Change default reliability from // BEST_EFFORT to RELIABLE: { // Correct pattern: get, modify, set DataReaderQos default = sub.get_default_datareader_qos(); default.reliability().kind() = RELIABLE; sub.set_default_datareader_qos(default); } // Create reader, forgetting new defaults: { DataReaderQos q; // <-- Don't allow this DataReader dr = sub.create_datareader(tp, q); // Reliability set back to BEST_EFFORT: dr.get_qos().reliability.kind() == ???; } Copyright © 2010 RTI - All rights Reserved 13
    14. 14. Still TO DO  We will ask for a vote at the December meeting  Review the PSM with your stakeholders – What do you like from each of the two current proposals? – What use cases do you have that are not met by either proposal?  Review the code license – (Will need AB, SMC guidance too) – What license should be used? BSD? – Who should hold copyrights: OMG only or OMG and submitters?  Will be further changes: – Unification of RTI and PrismTech proposals – Addition of DDS-XTypes APIs – Better alignment with Java PSM Copyright © 2010 RTI - All rights Reserved 14
    15. 15. The Real-Time Middleware Experts Q & A Copyright © 2010 RTI - All rights Reserved 15